OK. Found the next issue. It looks like sorting is not working correctly..
Do your unit tests spread items in different orders across two slices,
then makes sure they get merged in expected order?
I thought this was working before, but now it's not.
It is executing this query:
select this from
com.protrade.fandom.data.entities.fanwire.ArticleLinkComment this where
this.articleLink = :p0 AND this.act
ive = :p1 order by this.createTime asc
And it looks to get the lists of comments from each slice and merges
them without ordering them, so they come ordered from each slice, but
not interleaved..
Pinaki Poddar wrote:
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
