[
https://issues.apache.org/jira/browse/JCR-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065830#comment-13065830
]
Julian Reschke commented on JCR-3018:
-------------------------------------
I agree this isn't major, as it doesn't lead to corruption, and most certainly
is no regression.
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.
> 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
