I have a doubt regarding usage of ServiceLocator Design pattern. This pattern's intention is to remove the expense of Remote Lookups of EJBHome Interfaces, Connection Factory, Queue Names, Datasources by caching them in some datastructure and reusing them again, whenever required. IBM suggests and has a short paper on it website as well.
My concern is will this caching be a cause of concern in a Clustered Environment. For e.g. if we cache EJBHome for instance, and that particular server
in the cluster goes down, then the application will fail because it will keep getting the same EJBHome pointing to that appserver instance in that cluster which is down. Is there any way that Websphere provides to eradicate this problem ? Does Websphere allow some kind of configuration to remove this. There is something known as Clusterwide JNDI tree available in JBOSS. Do we have something like that in Websphere.
"JBoss has a cluster-wide JNDI tree that is replicated across the entire cluster. It requires no additional configuration and boots up with a cluster-enabled JBoss configuration. Remote JBoss JNDI clients can also implicitly use multicast to discover the JNDI tree"
If we have something like this in Websphere, we can use the ServiceLocator Design pattern without any issues in a Websphere Environment. This can be added as a good J2EE practice in my list.