Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Fri, 15 Jul 2011 09:20:59 +0000 (UTC)
From: "Stefan Guggisberg (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: 
 <683403062.16646.1310721659878.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <247883311.3343.1310399999864.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (JCR-3018) save leading to
 ReferentialIntegrityException leaves the repository in inconsistent state
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/JCR-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guggisberg updated JCR-3018:
-----------------------------------

    Priority: Minor  (was: Major)

AFAIK there's no risk of repository corruption involved.

a NodeImpl object, representing a transiently added new node,
is being reused after a failed save operation. the NodeImpl instance
has been rendered invalid through the failed save operation. methods 
called on this invalidated instance throw InvalidItemStateException. 

the session state however is not affected. retrieving a 'fresh' NodeImpl
instance after the failed save call avoids the problem.

> save leading to ReferentialIntegrityException leaves the repository in inconsistent state
> -----------------------------------------------------------------------------------------
>
>                 Key: JCR-3018
>                 URL: https://issues.apache.org/jira/browse/JCR-3018
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>            Reporter: Julian Reschke
>            Priority: Minor
>
> This is similar to JCR-2503.
> After a failed save() due to ReferentialIntegrityException and a subsequent successfull save() operation, nodes that were transient upon the first save and were persisted in the 2nd save will be corrupted, a getPath() operation failing with:
> javax.jcr.InvalidItemStateException: Item does not exist anymore: 75fe7eb7-7747-476e-bba8-c7f6b7f6e1a8
> 	at org.apache.jackrabbit.core.ItemImpl.itemSanityCheck(ItemImpl.java:116)
> 	at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:90)
> 	at org.apache.jackrabbit.core.ItemImpl.getPath(ItemImpl.java:376)
> The test is identical to the one added for JCR-2503, except that the node does not get refetched using getNodeByIdentifier.
> (test case follows)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira