[
https://issues.apache.org/jira/browse/JCR-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249510#comment-13249510
]
Unico Hommes commented on JCR-3289:
-----------------------------------
Patches against 2.4.1 tag
> Concurrent 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.4
> Reporter: Unico Hommes
> Priority: Critical
> Fix For: 2.4.2
>
> Attachments: ConcurrentAddMoveRemoveTest.patch,
> ItemSaveOperation.patch
>
>
> The scenario is as follows:
> 1. Thread thr1 does a move operation on node /folder1/node to destination
> /folder2/node
> 2. Thread thr2 does a remove operation on node /folder1/node
> 3. Thread thr1 does session save
> 4. Thread thr2 does session save
> 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.
> The test creates two nodes /folder1 and /folder2 and then executes the
> following operations concurrently:
> 1. add a node to either /folder1 or /folder2
> 2. remove a node from either /folder1 or /folder2
> 3. move a node from either /folder1 to /folder2 or vice versa
> On tearDown the workspace is checked for inconsistencies.
> Another patch is for the ItemSaveOperation class which fixes the issue. It's
> a proposed solution and I am not sure if this class is the right place to
> throw a StaleItemException or if there is a better solution than this but it
> is a proof of concept at the least.
--
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
