Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <438716CB.9010808@gmx.net>
Date: Fri, 25 Nov 2005 14:51:07 +0100
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: deadlock problem
References: <4382957B.4000600@osafoundation.org>
 <438296B7.9070908@osafoundation.org> <438498C8.1000201@osafoundation.org>
In-Reply-To: <438498C8.1000201@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Brian,

what revision of jackrabbit are you using? according to the line numbers 
in the thread dumps at least the SharedItemStateManager is not up to date.

there was an issue with locking some time ago.
http://issues.apache.org/jira/browse/JCR-194

is that fix included in your build?

Brian Moseley wrote:
> hey all, any thoughts on this problem?
> 
> the weird thing is, each of these 10 threads is reading/writing 
> different nodes with different parents, eg
> 
> /test1/testfile.txt
> /test2/testfile.txt
> ...
> /test10/testfile.txt
> 
> so it's baffling me why anything would be sharing locks for operations 
> on different nodes.
> 
> i notice in the javadocs for WriterPreferenceReadWriteLock that a 
> deadlock can occur if a thread tries to re-acquire a read lock that it 
> already holds, if there are also waiting writers. i also see in the 
> thread dump that multiple threads are waiting to both read and write.

this is correct for the lock you mentioned, but jackrabbit uses the 
reentrant variant of the lock which takes care of such situations.

> i wonder if maybe some thread called two read methods on a node without 
> the lock having been released after the first one. is that possible?
> 
> or do the SISM locks apply to all operations in a workspace? can 
> somebody explain the locking behavior of SISM?

a thread holds a write lock while a change is stored in the persistence 
manager. during that time no other thread can read from the SISM. events 
are delivered while holding a read lock, which is the formerly hold 
write lock downgraded to a read lock. thus synchronous (and of course 
also asynchronous) listeners are able to read again.
well, that's basically it ;)

currently quite simple but works well.

regards
  marcel