From dev-return-23704-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Mon Jun 08 15:34:18 2009 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 61218 invoked from network); 8 Jun 2009 15:34:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Jun 2009 15:34:16 -0000 Received: (qmail 13034 invoked by uid 500); 8 Jun 2009 15:23:04 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 10836 invoked by uid 500); 8 Jun 2009 15:22:59 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 6202 invoked by uid 99); 8 Jun 2009 15:20:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Jun 2009 15:20:46 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of stefan.guggisberg@gmail.com designates 209.85.220.214 as permitted sender) Received: from [209.85.220.214] (HELO mail-fx0-f214.google.com) (209.85.220.214) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Jun 2009 15:14:19 +0000 Received: by fxm10 with SMTP id 10so398928fxm.43 for ; Mon, 08 Jun 2009 08:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=YivinH43yXaXzLnwumm59hupeTnSjJl81f0MiSi8NhU=; b=ug6qJXJrTVSWZbrx+B4epttQRDXNZem4LaQozpbIXNfOIEAY4yTEULUVTL5rD+C6lU aJ4ZT5IrFgq9QLw539KfbaHa26f8qb4Sd/L0PCrLJuS8wO49OAgu7wm7VgeE6RW4kBBA fPDXrYKczEYa7TioHkugJqTol+wsIIQxunkBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ML6hwWFP/CziCiCzb/oDcbr/M17ac5QTYor/VP06oK8/VXlGrxeUv4vj/+CUiu2Kiq OQy0mB9Osf1h09fPlAPKrx9veH/xkjNPVnDO3W3Yp08eNm92rTYNNxMCT+lveiCqYLxI 8dFkV49jSp/vV/7sLujAbpzT0/x1MgaNaQ1EE= MIME-Version: 1.0 Received: by 10.223.122.141 with SMTP id l13mr4125614far.99.1244474038425; Mon, 08 Jun 2009 08:13:58 -0700 (PDT) In-Reply-To: <7A5837CEF4D4834E97721F3BCC46D7F71BC7753A58@darth-malak.gx.local> References: <7A5837CEF4D4834E97721F3BCC46D7F71BC7753A58@darth-malak.gx.local> Date: Mon, 8 Jun 2009 17:13:58 +0200 Message-ID: <90a8d1c00906080813h10d2a048n9fcf5ca1fb98b02f@mail.gmail.com> Subject: Re: Inconsistencies in the repository From: Stefan Guggisberg To: dev@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org hi martijn On Mon, Jun 8, 2009 at 4:17 PM, Martijn Hendriks wrote: > Hi all, > > We have quite some trouble with inconsistencies in our repositories. Afte= r some digging I found two scenario's that might result in inconsistent dat= a: > > The starting situation is that there are four nodes: /, /A, /A/B and /C > > (i) Corrupt parent-child relation > Thread 1 uses session1 to add node D to node A. > Thread 2 uses session2 to move /A/B to /A/C. > > After saving you might get the situation in which A still refers to B as = a child, but that B is moved to C. > > (ii) "Ghost" reference > Thread 1 uses session1 to add a reference property "ref to B" to C. > Thread 2 uses session2 to add a reference property "ref to B" to C. > > After saving you might get the situation in which two references to B exi= st. After deletion of C there still is a "ghost" reference which makes it i= mpossible to remove B due to referential integrity. > > I created https://issues.apache.org/jira/browse/JCR-2129 and have the fee= ling that the NodeStateMerger should handle these cases, but I am not sure.= If the NodeStateMerger should fix this, then I am afraid that the ItemStat= e and subclasses need to be changed as well in order to provide more detail= ed information on changes. I really want to fix this issue, but I am not su= re whether this is the right way. Any help, feedback or pointers are much a= ppreciated! Thanks! > i was able to reliably reproduce (ii) thanks to your test case (tanks btw). i don't think it's a NodeStateMerger problem. i guess (i.e. hope) that it can be fixed locally in SharedItemStateManager. it's basically about 2 or more threads creating the same property at the same time. the 1st thread succeeds and persists the new property (and records the refe= rence on the target in the case of a REFERENCE property). the next thread enters the write lock and doesn't realize that his 'new' property had been created in the mean time (again recording the reference on the target in the case o= f a REFERENCE property). the same issue doesn't appear with nodes new nodes have distinct uuid's. id's of new property's however may collide. cheers stefan > Best regards, > Martijn > > > -- > > Martijn Hendriks > creative online development B.V. > > t: 024 - 3888 261 > f: 024 - 3888 621 > e: martijnh@gx.nl > > Wijchenseweg 111 > 6538 SW Nijmegen > http://www.gx.nl/ > > >