openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravi Palacherla <>
Subject Reason for introducing lock inside statemanagerImpl.
Date Thu, 02 Jul 2009 18:00:16 GMT
Hi Pinaki,


I have a question regarding lock inside statemanagerImpl.

I see that it is introduced as part of HYPERLINK ""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
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:


A test case demonstrating the issue is  attached to the same JIRA  (HYPERLINK ""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/


--- openjpa-kernel/src/main/java/org/apache/openjpa/kernel/       (revision

+++ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/    (working

@@ -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();


+        }




      * 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() {




                                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,


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