[
https://issues.apache.org/jira/browse/JCR-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250807#comment-13250807
]
Bart van der Schans commented on JCR-3289:
------------------------------------------
Thanks for the patch and narrowing down the issue Unico! The patch looks good
to me.
Committed in trunk in revision 1311861.
I want to merge this in the 2.4 and 2.2 branches, but maybe somebody can have a
look at the patch as well?
> Remove operation right after move operation causes missing child inconsistency
> ------------------------------------------------------------------------------
>
> Key: JCR-3289
> URL: https://issues.apache.org/jira/browse/JCR-3289
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.11, 2.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.2.12, 2.4.2
>
> Attachments: ItemSaveOperation.patch, MoveRemoveTest.patch
>
>
> The scenario is as follows:
> 1. Session s1 does a move operation on node /folder1/node to destination
> /folder2/node
> 2. Session s2 does a remove operation on node /folder1/node
> 3. Session s1 is saved
> 4. Session s2 is saved
> A consistency check shows that /folder2 has a child node entry for inexistent
> child node node.
> The problem is that step 4. should fail whereas it doesn't.
> This is caused by the fact that the ItemSaveOperation.removeTransientItems
> puts the overlayed state of the transient state in the changelog instead of
> the transient state itself. But the overlayed state has the updated modcount
> of the previous move operation. Therefore when the shared item state manager
> persists the changelog it doesn't detect that the remove was done on a stale
> item and so the update can succeed.
> Attached is a patch containing a testcase that reproduces the inconsistency
> with this scenario.
> Another patch is for the ItemSaveOperation class which fixes the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
