A Diamond in the Rough

No, for once this has nothing to do with Ruby (deathly silence) rather, it concerns some problems many people have experienced when trying to use JNDI resources from Quartz jobs under Websphere.

In short, Websphere does not propogate any java:comp/env/ JNDI context to application created (ie non-container) threads. This is apparently by design with the upshot being that if you’re using quartz you won’t be able to use JDBC data sources from any jobs.

There a number of forum topics that discuss this problem along with various solutions including “use a 3rd-party connection pool instead.” Hardly music to the ears when you’ve just spend the last 3 months converting a customer’s entire application over to using JNDI resources. However, after much Googling, I happened upon an article that ultimately solved the problem in a Websphere-friendly manner. It even comes with sample code so you can get started almost immediately.

In essence, the solution makes use of Websphere’s Asychronous Beans (and the Work Manager in particular) as a sort of thread pool. We then took this idea and adapted it around the use of Quartz’s pluggable ThreadPool.

The final twist was the need to support both Websphere and Tomcat seamlessly without resorting to either build or deployment time configuration. For this we simply created a ThreadPool implementation that looks up the Work Manager in the JNDI context. If it exists, we assume that we’re in Websphere and go from there; otherwise we use the default Quartz implementation and hope for the best :)