Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of tobias.strasser@gmail.com
 designates 64.233.182.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=sNRnYiP+TxQxiXZpQtDP8s+bwjn2SWQyEaJJ5zFOZvHqOwyro3U7mL56pYwMVkfNs6OtpkG/36N59OKAy7N7WtlQ3jVfxB+96oSKPlfSrwpS8N/I5DDzYZwx08UHLfDzahQOsIn7Bg6dLIsgg2ic+Iw7Rg6gPzTnFhTrx8qjiy0=
Message-ID: <8be731880703140357g19b06745h2a7fd53eaa47a868@mail.gmail.com>
Date: Wed, 14 Mar 2007 11:57:49 +0100
From: "Tobias Bocanegra" <tobias.bocanegra@day.com>
Reply-To: tobias.bocanegra@day.com
Sender: tobias.strasser@gmail.com
To: dev@jackrabbit.apache.org
Subject: Re: Possible deadlock of jcr-server 1.2.1 (rmi)
In-Reply-To: <9f929f1c0703140339m7d12ca6lbb1f8d865cc6fe6e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E5E9E9A0-6164-4E06-BE22-8C1C5435BFB6@denali.be>
	 <45F7B6AD.70101@gmx.net>
	 <510143ac0703140155r54caaf58h7cfc17500bdd36e4@mail.gmail.com>
	 <9f929f1c0703140339m7d12ca6lbb1f8d865cc6fe6e@mail.gmail.com>

hi,
we analyzed the issue several times and most of the fixes were hacks
to prevent deadlocks and data corruption.
imo, we can't fixed the transaction/concurrency issues that occur
together with versioning without a bigger redesign of some of the core
parts of jackrabbit.

regards, toby

On 3/14/07, Miro Walker <miro.walker@gmail.com> wrote:
> We've been aware of this issue for a while. Unfortunately, the locking
> implementation is pretty hard to disentangle, and we haven't been able
> to come up with a fix. However, we have been able to work around it by
> adding an extra level of synchronisation in our own application that
> ensures only one simultaneous versioning operation can occur. I guess
> it depends how big a hit this would be as to whether it would be a
> suitable solution for anyone else.
>
> Miro
>
> On 3/14/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> > Hi,
> >
> > Seems like another case of the age-old JCR-18 issue with concurrent
> > versioning. Both of the updates contain some versioning operations,
> > and since concurrent versioning is at the moment still a rather
> > dangerous sport, I'm not surprised if bad things like a deadlock can
> > occur.
> >
> > Any contributions in further diagnosing and resolving the concurrent
> > versioning issues would be very much appreciated!
> >
> > BR,
> >
> > Jukka Zitting
> >
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---