Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of
 lists+1214986235816-210739@n2.nabble.com designates 216.139.236.158 as
 permitted sender)
Message-ID: <1229624261394-1674141.post@n2.nabble.com>
Date: Thu, 18 Dec 2008 10:17:41 -0800 (PST)
From: Pinaki Poddar <ppoddar@apache.org>
To: dev@openjpa.apache.org
Subject: Re: multithreaded, read/write?
In-Reply-To: <4949A894.3020903@alum.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4946CE0E.30707@alum.mit.edu>
 <75F3CF34-9110-49CD-95FA-D326BD57D08E@gmail.com>
 <4946F202.5080101@alum.mit.edu>
 <F8026E16-B6A9-465A-9C67-75414A473117@gmail.com>
 <4948356D.3010308@alum.mit.edu> <1229527748771-1668374.post@n2.nabble.com>
 <494984F8.8090608@alum.mit.edu> <4949A894.3020903@alum.mit.edu>


Hi,
  Thanks for your debugging analysis.

  PCPath extends CandidatePath is an aberration in the sense that none other
JDBC expression inherits their corresponding kernel expression.  I am not
convinced of that change (and said as much in the commit comment) because
there must be a strong reason why they did not inherit -- but I have not
analyzed or found out the reason yet.

Also, the in-memory query is not as comprehensively (that is an euphemism :)
tested as JDBC query and hence there is not much probe to validate such
changes.

However, while we can tweak this in-memory ordering to get it working -- the
limitation in threading model seems to me a more critical issue. The earlier
fix is not correct -- in fact I am seeing erratic, non-repeatable behavior
that points to my recent mangling of threading/locking. 

Given that a complete overhaul of kernel's threading model just to
accommodate Slice's parallel execution is out of scope, I have the following
changes in mind (not in code, yet):

1. If openjpa.Multithreaded=true, Slice queries will execute serially. The
existing threading model is comfortable with that, but the performance
advantage of Slice is compromised. That is OK, given that
openjpa.Multithreaded=true is not a common usage pattern.
2. If openjpa.Multithreaded=false, Slice queries will execute in parallel.
As it has been noted, this is not thread-safe with current threading/locking
policy. With the change, slices will lock the Broker/Query (i.e. any context
that the slices share) from StoreManager side as opposed to the user side. 
3. If we can make Broker/Query aware that which side (i.e. the user thread
or the internal slice thread) is locking, then that may avoid the deadlock
as well as guarantee thread-safety. 

  Thoughts?

-- 
View this message in context: http://n2.nabble.com/multithreaded%2C-read-write--tp1660098p1674141.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.