openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
Subject Re: multithreaded, read/write?
Date Wed, 17 Dec 2008 05:47:15 GMT

  Will someone comment on the code comments below? StateManagers using
Broker's lock amounts to  a coarse-grained lock indeed. What use case
scenario prompted this change?  

package org.apache.openjpa.kernel;

public class StateManagerImpl
     * Lock the state manager if the multithreaded option is set.
    protected void lock() {
        // use broker-level lock to avoid deadlock situations with the state
        // manager lock and broker lock being obtained in different orders

Fernando Padilla wrote:
> The stack traces are in the bug.
> Patrick Linskey wrote:
>> On Dec 15, 2008, at 4:10 PM, Fernando Padilla wrote:
>>> The current lock contention is StateManager locks against the Broker, 
>>> so essentially one global lock.  If someone were to deal with that, we 
>>> can move on and see where the next lock contention shows up! :)
>>> ( You can just look up who calls Broker.lock() )
>> What I meant was: what is actually going on when the calls are being 
>> made? Do you have any thread dumps during a bottleneck condition, for 
>> example?
>>> I guess the issue you're talking about is that you can't upgrade a 
>>> lock from Read to Write.  So if the code acquiring locks are all over 
>>> the place, it would be hard to guarantee that won't be attempted..
>> Yep. Synchronization in Java doesn't compose, so any additional 
>> complexity make things that much more difficult, maintenance-wise.
>> -Patrick
>>> Patrick Linskey wrote:
>>>> Hm. My experience with read/write locks in the past has been that it 
>>>> adds a fair amount of complexity, and opens up thorny issues when 
>>>> someone adds code that causes a section of code to become a 
>>>> write-requiring instead of a read-only section.
>>>> It might be interesting to analyze where contention starts piling up 
>>>> in the context of Slice, and see if there are any creative ways to 
>>>> reduce synchronization around those areas, maybe by having one lock 
>>>> for EM-level data structures and another that is used within 
>>>> StoreManagers. IOW, maybe there's an opportunity to transfer some 
>>>> level of synchronization to the StoreManager instead of the EM, which 
>>>> would mesh well with Slice's per-StoreManager parallelism.
>>>> If you go the read-write route, I think it'll be important to 
>>>> maintain something close to the current pathways as the default for 
>>>> existing applications (at least for a while), potentially by adding a 
>>>> new openjpa.Multithreaded value ('read-write' comes to mind).
>>>> -Patrick
>>>> On Dec 15, 2008, at 1:37 PM, Fernando Padilla wrote:
>>>>> So, if you guys have been following the mailing list, we've been 
>>>>> having some issues with slices requiring multithreaded support, but 
>>>>> the multithreaded support uses mostly a global lock, thus negating a

>>>>> huge performance gain used by Slices, where it executes queries in 
>>>>> parallel.
>>>>> So it looks like a long-term solution would be to review the locks 
>>>>> within OpenJPA and try to make them much more granular, but this 
>>>>> looks like it might be a very hard thing to do without everyone's 
>>>>> help, lots of unit tests, etc etc..
>>>>> I was wondering about another option, is to use Read/Write locks.  
>>>>> Maybe that will allow more granularity, allowing more threads to do 
>>>>> more work, without drastically changing the way things work.  ( We 
>>>>> would change all current locks to be writeLocks, then slowly change 
>>>>> them to readLocks on a case by case basis..)
>>>>> What are your thoughts towards an idea like this?
>>>>> If I can start to submit a few patches, would they be totally ignored?

View this message in context:
Sent from the OpenJPA Developers mailing list archive at

View raw message