[jira] Resolved: (JCR-756) Concurrent add/remove child node operations in a cluster may corrupt repository.

["Dominique Pfister (JIRA)" <ji...@apache.org>]

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

Dominique Pfister resolved JCR-756.
-----------------------------------

    Resolution: Fixed

Problem identified to be the following during an update:

1) When a journal update is started, the clustered instance syncs with journal contents. This 
    might  change the SharedItemStateManager's states
2) Later on, eventual, non-conflicting changes are merged to the local states. 
3) Finally, the journal update is prepared. This might again trigger an external update from
    the journal and change the shared states . However, these changes are not merged to the 
    local states.
4) The local states are pushed "blindly" to the shared states, potentially overwriting a previous
    change.

Fixed by locking the journal in 1) instead of 3). This still allows non-conflicting merge, but only once. An even
better, less blocking approach would iteratively merge the changes seen in external updates to the local states.

Thanks a lot to Rafał Kwiecień for reporting this bug and providing the test classes.

Fixed in revision 509624.

> Concurrent add/remove child node operations in a cluster may corrupt repository.
> --------------------------------------------------------------------------------
>
>                 Key: JCR-756
>                 URL: https://issues.apache.org/jira/browse/JCR-756
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.2.1
>            Reporter: Dominique Pfister
>         Assigned To: Dominique Pfister
>         Attachments: Create.java, Remove.java, repository.xml
>
>
> Concurrent add/remove child node operations in a cluster may store an inconsistent list of child node entries, i.e. an entry in the list may appear that has no associated node. This eventually results in an ItemNotFoundException, the next time one of these bogus entries is accessed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.