openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Linskey <plins...@gmail.com>
Subject Re: multithreaded, read/write?
Date Tue, 16 Dec 2008 04:37:32 GMT
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?

-- 
Patrick Linskey
202 669 5907


Mime
View raw message