Hi Fernando, Can you please pick up revision 727297 [1] and see if that works for your prototype/test harness? The changes are: a) slice queries minimize lookup to their shared context for isUnique() by caching the unique flag. This reduces one source of thread deadlock b) StateManagers use their own instance-level lock rather than locking the broker for everything. This reduces another source of thread deadlock. But this is a riskier change (though it did not show up any regression on OpenJPA test corpus). I am trying to find out why, at the first place, StateManagers were using the global Broker's lock. c) all slice queries run in parallel
I have noted that Slice should *always* run with openjpa.Multithreaded=true. If these changes (and similar ones but in the same direction -- rather than overhauling the threading model of the kernel) alleviate the deadlock while retaining the parallel execution at per-Slice level -- then I will change Slice configuration to enforce openjpa.Multithreaded=true. [1] http://n2.nabble.com/svn-commit%3A-r727297---in--openjpa-trunk%3A-openjpa-jdbc-src-main-java-org-apache-openjpa-jdbc-kernel--openjpa-kernel-src-main-java-org-apache-openjpa-kernel--openjpa-slice-src-main-java-org-apache-o-td1666666.html -- View this message in context: http://n2.nabble.com/multithreaded%2C-read-write--tp1660098p1668374.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
