Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (nike.apache.org: domain of plinskey@gmail.com designates
 209.85.200.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=bpg0KA5y1UvcSD3pHo51U6lnpnvddwOBSZFJshE+4dkvX3olw4Xlusmn+rmH/khm9L
         Ie6r0xwTfBb/treayUKyeEC2nzCMwyqpE0KK2A6qV+ztRSlIX7ozxyZw+v2JuA7NhhtE
         cfCvA02aHXbNgQoJGXdXXkGWF8Yf/2yNVDHdE=
Message-Id: <F8026E16-B6A9-465A-9C67-75414A473117@gmail.com>
From: Patrick Linskey <plinskey@gmail.com>
To: dev@openjpa.apache.org
In-Reply-To: <4946F202.5080101@alum.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: multithreaded, read/write?
Date: Mon, 15 Dec 2008 20:37:32 -0800
References: <4946CE0E.30707@alum.mit.edu>
 <75F3CF34-9110-49CD-95FA-D326BD57D08E@gmail.com>
 <4946F202.5080101@alum.mit.edu>

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