A Service Locator is typically implemented as a Singleton. However, J2EE applications run a J2EE container that typically uses multiple class loaders and JVMs, making it impossible to have a true Singleton with only one instance. Therefore, you might need multiple instances of the Service Locator in a distributed environment. However, since the Service Locator does not cache any data that needs to be concurrently accessed, you don't need to replicate and synchronize changes across these multiple instances.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Originally posted by suekar meredilko:
... if we create a cache for the ServiceLocator,
Originally posted by suekar meredilko:
... do we need to take care of how the application server has implemented the JNDI tree.
Originally posted by suekar meredilko:
For e.g. we need to know that is there a single JNDI server or multiple, if they are multiple are they synchronised.
Originally posted by suekar meredilko:
If one of the server goes down, will the servicelocator still work..assuming that it has cached the context of the jndi tree.
Originally posted by suekar meredilko:
... it will always fail even though the app is running on a different cluster.
Originally posted by suekar meredilko:
Do note that though JNDI is a standard in J2EE, how the JNDI servers are part of the vendors implementation as a container service. It may be centrally managed or distributed across.
www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
Originally posted by suekar meredilko:
How about J2EE servers providing clusters. In a cluster there is no Load balancer concept.
Originally posted by suekar meredilko:
Sorry...getting a bit deep here.
Originally posted by suekar meredilko:
Now if a serviceLocator is part of an EAR which is deployed in both servers.
Originally posted by suekar meredilko:
You meant to say that a singleton ServiceLocator will be then deployed in both the servers.
Originally posted by suekar meredilko:
a Service locator could do the following
1) Get the JNDI Context
2) Use the JNDI context to return Reference of Home (by which you can go ahead and store handles for later use and so on)
Now, what happens if I cache the JNDI context. If there is no load balancer am I right to say that servicelocator could pose problem if I start caching the context.
www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
Originally posted by suekar meredilko:
But again like I mentioned above ServiceLocator would be required by EJBs calling other EJBs.
www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
Originally posted by suekar meredilko:
No, if tehre is no load balancer, problems will arise.
www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
Originally posted by Thomas Taeger:
Suekar, I would like to understand:
- Which problems will arrise
- where and
- on which defects in which node?
Thomas
Originally posted by suekar meredilko:
If there is no load balancer [...]
www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
You save more money with a clothesline than dozens of light bulb purchases. Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|