Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Fri, 15 Jul 2011 10:25:59 +0000 (UTC)
From: "Stefan Guggisberg (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: 
 <25038809.16841.1310725559940.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <247883311.3343.1310399999864.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (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:comment-tabpanel&focusedCommentId=13065836#comment-13065836 ] 

Stefan Guggisberg commented on JCR-3018:
----------------------------------------

> On the other hand, we should discuss in the EG what the expectations are for the usability of Node objects after a failed save operation.

agreed

> 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