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