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.
