Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-3292

Workspace move in concurrent environment causes inconsistencies

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.11, 2.4
    • Fix Version/s: 2.2.12, 2.4.2, 2.5
    • Component/s: None
    • Labels:
      None

      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
      1. WorkspaceMoveTest.patch
        7 kB
        Unico Hommes
      2. JCR-3292.patch
        1 kB
        Unico Hommes

        Activity

        Hide
        Unico Hommes added a comment -

        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.

        Show
        Unico Hommes added a comment - 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.
        Hide
        Unico Hommes added a comment -

        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.

        Show
        Unico Hommes added a comment - 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.
        Hide
        Bart van der Schans added a comment -

        Committed in revision 1327180 with some minor changes to the unit test. The test is now part of the DailyIntegrationTest.

        Show
        Bart van der Schans added a comment - Committed in revision 1327180 with some minor changes to the unit test. The test is now part of the DailyIntegrationTest.
        Hide
        Bart van der Schans added a comment -

        Merged in the 2.4 branch in revision 1327442.

        Show
        Bart van der Schans added a comment - Merged in the 2.4 branch in revision 1327442.
        Hide
        Bart van der Schans added a comment -

        Merged in the 2.2 branch in revision 1327507.

        Show
        Bart van der Schans added a comment - Merged in the 2.2 branch in revision 1327507.

          People

          • Assignee:
            Bart van der Schans
            Reporter:
            Unico Hommes
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development