openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Padilla <>
Subject Re: multithreaded, read/write?
Date Thu, 18 Dec 2008 01:34:12 GMT
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(), 
             } 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 
> 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]


View raw message