I am running into what's listed as bug 987389 on sourceforge. Scott Stark says:
The problem is inconsistent
acquisition order of the two locks, m_cacheLock and cache id
BeanLock.
AbstractInstanceCache.get
-> synchronizes(m_cacheLock)
-> CachePolicy.insert()
...
-> LRUEnterpriseContextCachePolicy.ageOut
-> AbstractInstanceCache.release
-> AbstractInstanceCache.tryToPassivate
-> BeanLock.sync()
+ deadlocked waiting for BeanLock
LRUEnterpriseContextCachePolicy$OveragerTask.run
-> AbstractInstanceCache.tryToPassivate
-> BeanLock.sync()
-> synchronizes(m_cacheLock)
+ deadlocked waiting for m_cacheLock
The bug is closed, marked Fixed for 3.2.6RC2.
I am very interested in the fix for this bug, because I am running into deadlocks quite frequently, and would like to patch my 3.2.3 server. However, I cannot find this fix in CVS. There have been no recent changes to either AbstractInstanceCache or LRUEnterpriseContextCachePolicy that look relevant. An inspection of the code from the 3.2.6RC2 branch in CVS reveals the same problem... nothing at this level appears to have changed.
So, can someone kindly clarify what the status of this is? If it was fixed somewhere deeper, can you point me at the relevant change so I can apply a patch to my server? If the fix has not yet been submitted to CVS, can you provide an ETA for it?
Thanks,
Eli Daniel
