Hi Ravi, try (2). the change was brought in (if memory serves me right) for the case where multiple threads access a StateManager within a *single* broker. This happended when SliceStoreManager spawns threads to execute database operations. but after i made this change, i did modify further threading model behavior for Slice threads -- so this instance-level lock to StateManager *may be* redundant.
if you are trying (2), the multithreaded Slice tests are in slice module. Regards -- Pinaki Ravi Palacherla <[email protected]> 07/02/2009 01:00 PM To Pinaki Poddar <[email protected]> cc [email protected] Subject Reason for introducing lock inside statemanagerImpl. Hi Pinaki, I have a question regarding lock inside statemanagerImpl. I see that it is introduced as part of OPENJPA-825 ( r727297). Before that change statemanager used to rely on broker’s lock. As part of openjpa-825, a separate lock has been introduced for statemanager. Can you please help me understand the reason for introducing a separate lock for statemanager. Reason for my question : I am working on OPENJPA-453 on trunk ; the cause of the issue on trunk is Thread0 takes a reentrant lock inside BrokerImpl and waits to acquire reentrant lock inside statemanagerImpl. Thread1 takes a reentrant lock inside StatemanagerImpl and waits to acquire reentrant lock inside BrokerImpl. This is causing a deadlock. Details of the issue are under: https://issues.apache.org/jira/browse/OPENJPA-453#action_12725820 A test case demonstrating the issue is attached to the same JIRA ( OPENJPA-453_trunk_testcase.patch). There are two fixes I can think of to avoid the above issue: 1) To obtain broker’s lock before obtaining SM’s lock inside StateManagerImpl.lock() Here is an svn diff for this fix. Index: openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java =================================================================== --- openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java (revision 790413) +++ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/StateManagerImpl.java (working copy) @@ -3248,16 +3248,20 @@ * Lock the state manager if the multithreaded option is set. */ protected void lock() { - if (_instanceLock != null) + if (_instanceLock != null) { + _broker.lock(); _instanceLock.lock(); + } } /** * Unlock the state manager. */ protected void unlock () { - if (_instanceLock != null) - _instanceLock.unlock(); + if (_instanceLock != null) { + _instanceLock.unlock(); + _broker.unlock(); + } } private void writeObject(ObjectOutputStream oos) throws IOException { 2) Second is to go back to the original locking mechanism , that is statemanger will use broker’s lock. Code for SM’s lock and unlock will be: protected void lock() { _broker.lock(); } protected void unlock () { _broker.unlock (); } Before deciding on which path to take, I thought I have to understand the reason for introducing separate lock for statemanagerImpl. Thanks in advance, Ravi.
