jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Possible deadlock of jcr-server 1.2.1 (rmi)
Date Wed, 14 Mar 2007 13:25:29 GMT
Jukka Zitting wrote:
> Do we have some directions that seem worth pursuing? Would rethinking
> the locking mechanisms be enough, or do we need to fundamentally
> modify the basic ItemStateManager and VersionManager designs?

I haven't thought about this in much detail, but IMO the sequence how locks are 
acquired is the most problematic part of this issue. If we can ensure that locks 
are always acquired in the same sequence a deadlock shouldn't occur that easily.

Here's what I've been thinking about:

- Add a check to the SharedItemStateManager (SISM) if it has 
VirtualItemStateProvider (VISP). This will be the case for the workspace SISM, 
but not for the SISM in the version manager. Furthermore if the change log 
contains references into one of the VISPs, those VISPs must be write locked 
*before* this SISM is write locked. Otherwise only this SISM needs to be locked.

This should ensure that the lock sequence is always: VISP and then SISM.

I'm not sure about the lock in AbstractVersionManager (AVM), but since the AVM 
is on a higher layer than the VISP the overall lock sequence should be: AVM, 



View raw message