<p>It appears that our implementation of using Quartz - JDBCJobStore along with Spring, Hibernate and Websphere is throwing unmanaged threads.  </p>

<p>I have done some reading and found a tech article from IBM stating that the usage of Quartz with Spring will cause that.  They make the suggestion of using CommnonJ to address this issue.</p>

<p>I have done some further research and the only examples I have seen so far all deal with the plan old JobStore that is not in a database.</p>

<p>So, I was wondering if anyone has an example of the solution for this issue.</p>

<p>Thanks</p>

We have a working solution for this (two actually).
1) Alter the quartz source code to use a WorkManager daemon thread for the main scheduler thread.  It works, but requires changing quarts.  We didn't use this though since we didn't want maintain a hacked version of quartz.  (That reminds me, I was going to submit this to the project but completely forgot)
2) Create a WorkManagerThreadPool to be used as the quartz threadpool.  Implement the interface for the quartz ThreadPool, so that each task that is triggered within quartz is wrapped in a commonj Work object that will then be scheduled in the WorkManager.  The key is that the WorkManager in the WorkManagerThreadPool has to be initialized before the scheduler is started, from a Java EE thread (such as servlet initialization).  The WorkManagerThreadPool must then create a daemon thread which will handle all the scheduled tasks by creating and scheduling the new Work objects.  This way, the scheduler (on its own thread) is passing the tasks to a managed thread (the Work daemon).
Not simple, and unfortunately I do not have code readily available to include.