Hi,

I have a spring integrated web application using JPA/hibernate 3. We have been having some memory performance issues and so connected JConsole to out test machine. Looking at the threads I noticed that we have a couple of threads per JPA entity, e.g.:

my.domain.EntityOne.data
my.domain.EntityOne Spool Thread

my.domain.EntityTwo.data
my.domain.EntityTwo Spool Thread

Does anyone know why on earth there are two threads being allocated for each entity? The EntityManager is a spring injected singleton entity manager which apparently sorts out the non threadsafe JPA EntityManager issues. But I cannot concieve it handles the EntityManager concurrency by creating a seperate thread for each entity/entityManager?

I have absolutly no idea what these threads are for. Any insight would be apprecieated.

Just looked more closely and the sppol thread stack trace shows its associated with the ehcache diskstore. So thats explains that I guess.

But still dont understand the my.domain.EntityOne.data threads for each JAP entity.

Stack trace for these shoes a ThreadPoolExecutor:

tack trace:
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:146)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1879)
java.util.concurrent.DelayQueue.take(DelayQueue.java:135)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:533)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:526)
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
java.lang.Thread.run(Thread.java:637)


Dont know what created them or why it was created.

Tim,
These threads are created when the "overflowToDisk" property is enabled (which is the default).
They are started by a call to "ScheduledThreadPoolExecutor" in the "DiskStorageFactory" constructor.
They implement the "DiskExpiryTask".
Regards,
metatech