[ https://jira.jboss.org/jira/browse/JBPM-1766?page=com.atlassian.jira.plug... ] joe freeman updated JBPM-1766: ------------------------------ Description: The code in getLeavingTransitionsMap() lazily constructs the map the first time the method is called. Our application can have 100s of users going through the same node at the start of their shift. It is possible to have more than one user leaving the first node at the same time in the same VM. This can put multiple users in the getLeavingTransitionsMap() method at the same time. We can get deadlock in the put() method for the map which means no one else can enter the application. The block of code should be synchronized or the map should be synchronized. A simpler fix is to just remove the map. The number of transitions exiting a node is unlikely to ever be large enough to justify the complexity of two data structures pointing at the same objects. Iterating across the list is almost always going to be close enough in performance to remove the need for this map. We're running just the jpdl which has this problem up through and including the current 3.2.3 version /** * are the leaving {@link Transition}s, mapped by their name (java.lang.String). */ public Map getLeavingTransitionsMap() { if ( (leavingTransitionMap==null) && (leavingTransitions!=null) ){ // initialize the cached leaving transition map leavingTransitionMap = new HashMap(); ListIterator iter = leavingTransitions.listIterator(leavingTransitions.size()); while (iter.hasPrevious()) { Transition leavingTransition = (Transition) iter.previous(); leavingTransitionMap.put(leavingTransition.getName(), leavingTransition); } } return leavingTransitionMap; } was: The code in getLeavingTransitionsMap() lazily constructs the map the first time the method is called. Our application can have 100s of users going through the same node at the start of their shift. It is possible to have more than one user leaving the first node at the same time in the same VM. This can put multiple users in the getLeavingTransitionsMap() method at the same time. We can get deadlock in the put() method for the map which means no one else can enter the application. The block of code should be synchronized or the map should be synchronized. We're running just the jpdl which has this problem up through and including the current 3.2.3 version /** * are the leaving {@link Transition}s, mapped by their name (java.lang.String). */ public Map getLeavingTransitionsMap() { if ( (leavingTransitionMap==null) && (leavingTransitions!=null) ){ // initialize the cached leaving transition map leavingTransitionMap = new HashMap(); ListIterator iter = leavingTransitions.listIterator(leavingTransitions.size()); while (iter.hasPrevious()) { Transition leavingTransition = (Transition) iter.previous(); leavingTransitionMap.put(leavingTransition.getName(), leavingTransition); } } return leavingTransitionMap; } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1766?page=com.atlassian.jira.plug... ] joe freeman commented on JBPM-1766: ----------------------------------- A given Node in a given ProcessDefinition is essentially a singleton for that ProcessDefinition. The ProcessDefinition is essentially a singleton shared across all ProcessInstances that use it. So the Node is essentially a singleton shared across all ProcessInstances using the containing ProcessDefinition. Each ProcessInstance only runs in one thread but they can share Processes Definitions. This normally isn't an issue because the attributes of the ProcessDefinition and its contained components are initialized at creation time. That means that the ProcessDefinition components are essentially thread safe for the purposes of the JBPM. No thread modifieds data used by other threads. The leavingTransitionMap is one of the very few exceptions to this behavior. The leavingTransitionMap is initialized by the first thread that calls getLeavingTransitionMap(). That initialization is used by all other threads using that Node in its containing ProcessDefinition. The problem is that it is possible for multiple threads to be in that method at the same time. This means multiple threads can be populating leavingTransitionMap at the same time. I believe that the hibernate mappings for Node show that it is cached in the secondary cache so that all processInstances that reference it through it's containing ProcessDefinition share the same Node instance, retrieving it from the cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-1766?page=com.atlassian.jira.plug... ] Tom Baeyens commented on JBPM-1766: ----------------------------------- " I believe that the hibernate mappings for Node show that it is cached in the secondary cache so that all processInstances that reference it through it's containing ProcessDefinition share the same Node instance, retrieving it from the cache. " this is incorrect. hibernate maintains the data tupelized (think hashmaps) in the 2nd level cache. from that cache, new object instances are created for each session. try writing a test case in which you look up a node in a process definition in 2 different hibernate sessions and see if they are the same. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira