In http://java.sun.com/j2se/1.3/docs/api/javax/naming/InitialContext.html, it says "An InitialContext instance is not synchronized against concurrent access by multiple threads. Multiple threads each manipulating a different InitialContext instance need not synchronize. Threads that need to access a single InitialContext instance concurrently should synchronize amongst themselves and provide the necessary locking."
Does the above apply to bind(), and unbind() only? Since lookup() seems read-only to me, should I create a static class that return the same Context, and use it everywhere to get my JNDI resources?
Since looking up repeatly for the same home object in each method call takes resource and time, putting "(new InitialContext()).lookup()" inside a method isn't a good approach. Should we put the Context as a private member variable? In the EJB case, this is fine as each method call is thread-safe. I put "this.ctx = new InitialContext()" in the session bean's ejbCreate method. But which callback method should I initialize the Content member in the CMP Entity bean case?
For the servlet/static class case, putting Context as a member variable may introduce concurrent problems. Any suggestion for maximize conncurrency and a thread-safe solution? I want to avoid calling "(new InitialContext()).lookup()" in each call
What about storing the EJBHome Objects as member variable instead? Will this degrade JNDI clustering? Does a EJBHome Object's method thread-safe?
