Deadlock in StatefulSessionFilePersistenceManager when too many ejb clients for ejb3 cache
maxSize
--------------------------------------------------------------------------------------------------
Key: EJBTHREE-2273
URL:
https://issues.jboss.org/browse/EJBTHREE-2273
Project: EJB 3.0
Issue Type: Bug
Components: core
Reporter: David Stephan
Fix For: Unscheduled
The problem is in SimpleStatefulCache.
Consider what happens when you load a passivated SFSB instance:
1) org.jboss.ejb3.cache.simple.SimpleStatefulCache.get() is called
2) it synchronizes on this.cacheMap and checks if it is in memory
3) when it's not, it enters the second part of the code, synchronizing on this.pm and
then this.cacheMap
4) it checks for the passivated bean
So the locking order is the StatefulSessionPersistenceManager first and then the CacheMap
second
Consider what happens when you create a new SFSB instance, which causes an old one to be
passivated:
1) org.jboss.ejb3.cache.simple.SimpleStatefulCache.create() is called
2) after creating the instance, it synchronizes on this.cacheMap and calls cacheMap.put()
3) when the cache is full, CacheMap.removeEldestEntry() is called
4) if it can passivate the bean, it calls SimpleStatefulCache.passivate()
5) that method synchronizes on this.pm
So the locking order is CacheMap first and StatefulSessionPersistenceManager second.
Not having the same locking order will cause this deadlock if more than one thread is
involved, and SimpleStatefulCache.get() and SimpleStatefulCache.create() are invoked
concurrently.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira