jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-3289) Remove operation right after move operation causes missing child inconsistency
Date Mon, 09 Apr 2012 11:29:18 GMT

     [ https://issues.apache.org/jira/browse/JCR-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Unico Hommes updated JCR-3289:
------------------------------

    Description: 
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.


  was:
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.


        Summary: Remove operation right after move operation causes missing child inconsistency
 (was: Concurrent remove operation right after move operation causes missing child inconsistency)
    
> 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

        

Mime
View raw message