You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Julian Reschke (JIRA)" <ji...@apache.org> on 2011/07/11 17:59:59 UTC

[jira] [Created] (JCR-3018) save leading to ReferentialIntegrityException leaves the repository in inconsistent state

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


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

        

[jira] [Commented] (JCR-3018) save leading to ReferentialIntegrityException leaves the repository in inconsistent state

Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063420#comment-13063420 ] 

Julian Reschke commented on JCR-3018:
-------------------------------------

test case added with r1145226: NodeImplTest.testReferentialIntegrityCorruptionGetPath; it's currently disabled in pom.xml (as known failure)

> 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
>
> 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

        

[jira] [Commented] (JCR-3018) save leading to ReferentialIntegrityException leaves the repository in inconsistent state

Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
    [ 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

        

[jira] [Updated] (JCR-3018) save leading to ReferentialIntegrityException leaves the repository in inconsistent state

Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
     [ 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

        

[jira] [Commented] (JCR-3018) save leading to ReferentialIntegrityException leaves the repository in inconsistent state

Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
    [ 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