I am relatively new to clustering so please do not send me to read documentation. I have read all I could find.
I also read JBoss documentation on clustering but yet I do not entirely understand. At the end of the message there is a quote from JBoss documentation but I still need explanation in plain language. Can anyone please answer????
I think about implementing ServiceLocator that caches home interfaces in a cluster. Yes, I know that it will be a one singleton per JVM. So I have 3 nodes, I will have 3 singletons. Is there a problem with that?
In a clustered environment (JBoss 4.0.5, a few nodes, sticky is off) are home interfaces bound to a specific node in the cluster or not? In other words can I or can I not...?
1. can I safely cache reference to a home interface (EJBHome) to a session bean in a ServiceLocator ?
2. can I safely cache reference to a home interface to a entity bean in a ServiceLocator ?
3. can I safely cache LOCAL home interface (EJBLocalHome) in a ServiceLocator ?
I use HA-JNDI (I think that I do since I put "localhost:1100" into Context.PROVIDER_URL). This means I DO use HA-JNDI. Correct?
I create InitialContext as:
Hashtable environment = new Hashtable();
return new InitialContext(environment);
and I use True in META-INF\jboss.xml for all my beans
Below is a quote from section 1.2.1 How it works from "The JBoss 4 Application Server Clustering Guide " On the server side, new InitialContext(), will be bound to a local-only, non-cluster-wide JNDI Context (this is actually basic JNDI). So, all EJB homes and such will not be bound to the cluster-wide JNDI Context, but rather, each home will be bound into the local JNDI. When a remote client does a lookup through HA-JNDI, HA-JNDI will delegate to the local JNDI Context when it cannot find the object within the global cluster-wide Context. The detailed lookup rule is as follows.
- If the binding is available in the cluster-wide JNDI tree and it returns it.
- If the binding is not in the cluster-wide tree, it delegates the lookup query to the local JNDI service and returns the received answer if available.
- If not available, the HA-JNDI services asks all other nodes in the cluster if their local JNDI service owns such a binding and returns the an answer from the set it receives.
- If no local JNDI service owns such a binding, a NameNotFoundException is finally raised."
Thanks to anyone who answers or just reads....
I can advise about HA-JNDI. If you use the provider url of localhost:1100, your context will be associated with HA-JNDI. If you then lookup objects via that context, the lookup will utilize HA-JNDI. If you bind something using that context, the binding will be stored in HA-JNDI and replicated throughout the cluster.
Note that all JNDI bindings can be listed using the JNDIView service. From the JMX Console, select service=JNDIView and then invoke either the list( ) or listXML( ) methods. The output will display all of your JNDI bindings. The last section of the output shows HA-JNDI bindings; anything listed here is stored in HA-JNDI and replicated on all nodes.
HA-JNDI will successfully lookup any JNDI binding, regardless of which node has the binding. Standard JNDI will only successfully lookup any JNDI (not HA-JNDI) binding on the node associated with the lookup request.
do you know how local interfaces work in HA-JNDI ? Say, I created the context the way I described above and looked up a local home interface using HA-JNDI on nodeA. Now, say this reference to EJBLocalHome gets passed to nodeB (as an instance variable of a Session Bean or if I save it in a session, or whatever other way). Hence is the question. What will happen to with it on nodeB if it was created in nodeA ????
My wrote a small tests and it works fine. The reference to local home interface gets passed to another node and component interface is successfully created but I do not understand why it does not fail !!!. Local interfaces are not supposed to be juggled like remote interfaces, are they???
Would most appreciate an opinion on the matter.
What gets passed around the cluster is a proxy to the bean. The proxy to a local interface can only talk to an invoker using local calls, not remote. But, if the EJB container it targets is also deployed on the node the proxy gets passed to, the proxy will be able to make calls on it.
Thanks Brian. It's been very helpful.