Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 fern@alum.mit.edu does not designate 66.111.4.25 as permitted sender)
Message-ID: <494984F8.8090608@alum.mit.edu>
Date: Wed, 17 Dec 2008 15:02:16 -0800
From: Fernando Padilla <fern@alum.mit.edu>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: dev@openjpa.apache.org
Subject: Re: multithreaded, read/write?
References: <4946CE0E.30707@alum.mit.edu>
 <75F3CF34-9110-49CD-95FA-D326BD57D08E@gmail.com>
 <4946F202.5080101@alum.mit.edu>
 <F8026E16-B6A9-465A-9C67-75414A473117@gmail.com>
 <4948356D.3010308@alum.mit.edu> <1229527748771-1668374.post@n2.nabble.com>
In-Reply-To: <1229527748771-1668374.post@n2.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
> 
>