It looks like PCPath extends CandidatePath, but that fails:
around CandidatePath, line 139
try {
// get the specified field value and switch candidate
Traversal traversal = (Traversal) action;
candidate = sm.fetchField(traversal.field.getIndex(),
true);
} finally {
The _actions list contains PCPath$Action, which does not extend
Traversal, so we get a class-cast exception here in the code, and thus
the "getOrderingValue" method called by
OrderingMergedResultObjectProvider returns null.. thus it does not get
any of the appropriate field values to run it's sorting against.. thus
everything remains unsorted..
If you remember, PCPath was extending a different class until a few
weeks ago.. so I guess PCPath and CandidatePath require a little more
work :)
Fernando Padilla wrote:
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
