You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Unico Hommes (Created) (JIRA)" <ji...@apache.org> on 2012/04/16 13:58:18 UTC
[jira] [Created] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
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.4, 2.2.11
Reporter: Unico Hommes
Attachments: 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
[jira] [Commented] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Bart van der Schans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256421#comment-13256421 ]
Bart van der Schans commented on JCR-3292:
------------------------------------------
Merged in the 2.4 branch in revision 1327442.
> 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
> Assignee: Bart van der Schans
> 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
--
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
[jira] [Commented] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Bart van der Schans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256559#comment-13256559 ]
Bart van der Schans commented on JCR-3292:
------------------------------------------
Merged in the 2.2 branch in revision 1327507.
> 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
> Assignee: Bart van der Schans
> Fix For: 2.2.12, 2.4.2, 2.6
>
> 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
--
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
[jira] [Resolved] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Bart van der Schans (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bart van der Schans resolved JCR-3292.
--------------------------------------
Resolution: Fixed
Fix Version/s: 2.6
2.4.2
2.2.12
> 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
> Assignee: Bart van der Schans
> Fix For: 2.2.12, 2.4.2, 2.6
>
> 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
--
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
[jira] [Commented] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Bart van der Schans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255716#comment-13255716 ]
Bart van der Schans commented on JCR-3292:
------------------------------------------
Committed in revision 1327180 with some minor changes to the unit test. The test is now part of the DailyIntegrationTest.
> 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
> Assignee: Bart van der Schans
> 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
--
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
[jira] [Updated] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Unico Hommes updated JCR-3292:
------------------------------
Attachment: WorkspaceMoveTest.patch
Note that you need to have patches in issues JCR-3290 and JCR-3289 applied to isolate this particular issue. Otherwise this test case will also produce the inconsistencies mentioned in those issues.
> 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: 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
[jira] [Updated] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ 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
> 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
--
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
[jira] [Updated] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-3292:
-------------------------------
Fix Version/s: (was: 2.6)
2.5
> 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
> Assignee: Bart van der Schans
> Fix For: 2.2.12, 2.4.2, 2.5
>
> 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
--
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
[jira] [Updated] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Unico Hommes updated JCR-3292:
------------------------------
Attachment: (was: JCR-3292.patch)
> 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
--
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
[jira] [Assigned] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Bart van der Schans (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bart van der Schans reassigned JCR-3292:
----------------------------------------
Assignee: Bart van der Schans
> 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
> Assignee: Bart van der Schans
> 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
--
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
[jira] [Updated] (JCR-3292) Workspace move in concurrent
environment causes inconsistencies
Posted by "Unico Hommes (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Unico Hommes updated JCR-3292:
------------------------------
Description:
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
was:
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.
> 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
--
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