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-3292) Workspace move in concurrent environment causes inconsistencies
Date Mon, 16 Apr 2012 19:44:19 GMT

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

Unico Hommes updated JCR-3292:

    Attachment: JCR-3292.patch

Taking another look, I discovered I was mistaken in thinking that this issue could not be
easily solved. I figured that by disconnecting the nodes earlier from the underlying overlayed
state the changes would not be overwritten. And apparently there has been a very similar issue
in the past where exactly this approach was taken. See JCR-2269. Attached is a patch that
solves the issue in the same way.
> Workspace move in concurrent environment causes inconsistencies
> ---------------------------------------------------------------
>                 Key: JCR-3292
>                 URL: https://issues.apache.org/jira/browse/JCR-3292
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>    Affects Versions: 2.2.11, 2.4
>            Reporter: Unico Hommes
>         Attachments: JCR-3292.patch, WorkspaceMoveTest.patch
> Attached is a test case that shows that using workspace move concurrent with other write
operations causes inconsistencies.
> The problem is that unlike session move, workspace move operates on the local item state
directly (session move operates on transient item state). When a concurrent modification occurs
on for instance the source parent of the moved target the modification that the move operation
was trying to do is overwritten as the changes from the concurrent session are pulled in:
> - on thread 1 a workspace.move is initiated on /folder1/node to /folder2/node, removing
the child node entry from /folder1 a.o.t.
> - session 2 on thread 2 modifies and saves /folder1, overwriting the changes on the local
item state of /folder1 in session 1 
> - thread 1, still in the workspace move operation, sends the updates to the shared item
state manager
> I don't see any easy fixes for this problem. Probably the design of the BatchedItemOperation
needs to modified quite a bit.

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


View raw message