openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
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 

Regards --


Ravi Palacherla <> 
07/02/2009 01:00 PM

Pinaki Poddar <>
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 
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:
A test case demonstrating the issue is  attached to the same JIRA  (
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 
Here is an svn diff for this fix.
      (revision 790413)
   (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();
+        }
      * 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