openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <ppod...@us.ibm.com>
Subject Re: Reason for introducing lock inside statemanagerImpl.
Date Thu, 02 Jul 2009 18:47:16 GMT
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 <ravi.palacherla@oracle.com> 
07/02/2009 01:00 PM

To
Pinaki Poddar <ppoddar@apache.org>
cc
dev@openjpa.apache.org
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message