• Post Reply Bookmark Topic Watch Topic
  • New Topic

Optimizing JNDI lookups.  RSS feed

 
Mike Curwen
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

One of the tips about optimizing EJB's is to cache any information obtained through a JNDI lookup.

For example, if you are using an Integer to control a loop, and you want to make this Integer a configurable option, then don't do an expensive lookup operation each time before you do the loop. In the setEntityContext of your EJB, you'd do the lookup once, and use the local copy each time you do your loop.

Here is a question: Does anyone know of any trouble with caching a DataSource object? As far as I can tell, it's a ConnectionFactory of some sort, so are there any issues with doing a lookup on this object, caching it in my bean, and then using it in my methods.

The thing I'm trying to anticipate is that the container may decide to tear down the connectionfactory "in the meantime", and the cached copy would throw a SQLException when I try to do a .getConnection().

Any thoughts on this?
 
Jim Baiter
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With one of the seasoned app servers like Weblogic it probably won't matter because it will use a connection pool and JNDI will look up the connection locally. You may want to cache the InitialContext but that's probably about it.
 
Steve Chernyak
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just a thought...
Why not place the getConnection call inside a try\catch block and handle the exception by looking up a new DataSource from JNDI
Anybody have thoughts on this.
 
Mike Curwen
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had thought of using try/catch, and this is a while back, so maybe i'm not explaining it right...

When I investigated, the only exception that would be thrown when and if I called getConnection on a remote object that isn't there anymore, is a SQLException. So how could I tell if the problem was that the container had torn down the connectionfactory that my cached reference formerly referred to, or if the thing was actually there, but there is really a SQL error.

I suppose I can simply ensure that my SQL is perfect, and that the database is perfect... but after all, SQLException is an *exception*, designed to catch things not thought of, or things that happen at runtime that have nothing to do with poor code.

Further suppose that I could simply assume the SQLException is being caused by a null remote connectionfactory, and try to make a new one and re-try the getConnection... But it seemed a bit sloppy.

Anyone else have thoughts?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!