Proper use of javax.naming.InitialContext

[arabung]

I've seen conflicting advice on the proper lifetime of a javax.naming.InitialContext object. On one hand, some people advise that an InitialContext is a limited resource, to be created when needed, and released shortly thereafter, like a database connection. Others have advised that intantiation is the only resource-intensive aspect of InitialContext, and they should be "kept around" by an object as an instance variable to avoid redundant instantiation. More simply, should InitialContexts be used like this:

public class SimpleServlet extends HTTPServlet {
private InitialContext myContext;

public void init(ServletConfig _config) {
myContext = new InitialContext();
.....
}

..some methods that use getContext()..

private InitialContext getContext() {
return myContext;
}

Or, should the context be more short lived:

public class SimpleServlet extends HTTPServlet {

public void init(ServletConfig _config) {
.....
}

..some methods that use getContext()..
..they also take care to close InitialContext objects..

public InitialContext getContext() {
return new InitialContext();
}

[twhphan]

Context has a close() method. It is better to be executed manually, although the garbage collection will pick that eventually

I think caching the home references is a better approach, but I'm not sure if this affects security, since the first caller's access may be cached as well. In addition, does multiple JVMs may imply multiple home references for the same EJB? If I cache a home reference, will I always get to one of my JVM's home/remote bean?

Looking up references in each client invocation is costly, any guideline? pls advise, thx

[alu1344]

This far I have been caching home references, not JNDI contexts. I suppose that in your case you can do the same.

Sun has design patterns that recommend to cache home references, but I can't recall any that keeps the jndi context. Anyway, the only case where you should want to keep one is inside an EJB object, and this far I haven't seen anybody doing it yet (everybody instantiates the InitialContext on ejbCreate or at lookup time, e.g. new InitialContext().lookup("mybean")). This solution is fine for me.

I made a simple debugging servlet a week or so ago to show the JNDI Context instantiation and lookup time on a butg loop and it is very low (I cannot remember the numbers, though)

[user57]

The exact behavior of an InitialContext is provider specific, so it is hard to come up with a generalized aporache to handling it.

In general, you must assume there are some resources asscocated with the IC, thus you don't want to waste them by leaving unused/idle IC laying around.

So, if you just need todo a few look ups, then create a new IC, look up your goodies and then close it. This will make sure that the resources required are free to be used by some other process (or IC lookup).

On the other hand, if your app requires constant access to naming, then you might want to keep an IC around, as there is a cost to allocate the resources required for it to operate.

And don't forget to call close()... you never know when it will get called during finialization.

--jason

[twhphan]

Beside caching the IC, what about caching the home reference (or the remote reference)?

How does JBoss handle the lookup for a home reference? Is it safe to cache the home reference? As far as I know, the xdoclet generated util class caches the home reference. But in Sun Pet Store demo code, I don't see any caching code.