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 00:10:42 GMT
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() )



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





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