openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Padilla <f...@alum.mit.edu>
Subject Re: multithreaded, read/write?
Date Tue, 16 Dec 2008 23:10:37 GMT
The stack traces are in the bug.

https://issues.apache.org/jira/browse/OPENJPA-825



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?
> 

Mime
View raw message