This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm maintaining some old EJB code. Right now, there is a Session Bean method that stores a piece of information into JNDI. The next time the method runs, it reads the information back. That seems to work fine now, but I suspect that if we ever deploy to a cluster, there will be problems. The second time the method is run could be on a different server with a different JNDI tree. Am I right about that?
JNDI is an important topic, and there are many ways to configure JNDI names. The need for using JNDI references in the deployment descriptors embodies the fact that actual JNDI names can change, and programs must be ready for that.
With WebSphere, we have the whole federated namespace, which actually provides about 5 potential means of doing a JNDI indirection, all of which make sense in various situations. It's alot to digest when you're just happy that your JNDI lookup on your local machine worked properly.
Here's an article I wrote on JNDI. It's WebSphere focussed, but the ideas are universal.
It also depends on the cluster implementation. Since I know JBoss I can let you know how it is implemented. In JBoss, JNDI is replicated, so in the jndi.properties file you can either provide a Multi-cast IP address for the cluster at large, and it can get the information. Or you can provide each and every IP address in the cluster.
Since JNDI is replicated, how it is replicated comes into play on whether it is synchronous replication or asynchronous. with asynchronous, it is possible that the last say 20 seconds of changes hasn't been received on the new node that you are now talking to, but that is a trade off that you need to figure out because how ofter in your cluster does a node go down. Also if you have synchronous, then performance is hit.
Lots about this subject, that research is in order.
Since JNDI is replicated, how it is replicated comes into play on whether it is synchronous replication or asynchronous
I believe with JNDI replication you replicate the copy of JNDI tree on the other nodes of the cluster but not the object's binded to the JNDI. I too have question on this.
Assuming I have two servers A, B and user call is routed to Server A which initialize a object (since first time) and binds to JNDI tree. The object bounded by Server A lives in Server A JVM, isn't it? - What will happen if Server A which created and bounded the Object to JNDI goes down? Sure Server B will have replicated the JNDI copy of Server A but will it be able to resolve the object bounded by Server A? - Or is the object bounded to server A is replicated on Server B? I guess this will have more memory/performance/version problems - In weblogic we need to specify the objects (EJB Stub) that are to be replicated in the configuration which make me believe replication is not the default option. I couldn't find a way to create any object, bind to JNDI and get it replicated.