openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
Subject Re: multithreaded, read/write?
Date Thu, 18 Dec 2008 18:17:41 GMT

  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

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. 


View this message in context:
Sent from the OpenJPA Developers mailing list archive at

View raw message