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

Improve handling of concurrent node modifications

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.1
    • Component/s: jackrabbit-core
    • Labels:
      None

      Description

      consider the following scenario:

      • session1 modifies node /a by adding a child node b
      • session2 modifies node /a by adding a child node c
      • session2 saves its changes
      • session1 tries to save its changes which results in a InvalidItemStateException

      this behavior is in accordance with the spec. the spec however doesn't prevent a
      more lenient handling of this scenario.

      if the concurrent modifications are non-conflicting and trivial the changes could
      be silently merged in session1's transient state of node /a.

      examples for trivial non-conflicting changes:

      • s1 adds child node a, s2 removes child node b
      • s1 adds child node a, s2 adds child node b
      • s1 adds child node a, s2 adds mixin type

      examples for non-trivial and/or conflicting changes:

      • s1 removes child node a, s2 removes child node a
      • s1 adds child node a, s2 adds child node a
      • s1 adds sns child node a (> a[3]), s2 adds sns child node a (> a[3])
      • s1 adds sns child node a (-> a[3]), s2 removes sns child node a[1]
      • s1 removes sns child node a[2], s2 reorders child nodes affecting sns nodes a

        Activity

        Stefan Guggisberg created issue -
        Stefan Guggisberg made changes -
        Field Original Value New Value
        Description consider the following scenario:
        - session1 modifies node /a by adding a child node b
        - session2 modifies node /a by adding a child node c
        - session2 saves its changes
        - session1 tries to save its changes which results in a InvalidItemStateException

        this behavior is in accordance with the spec. the spec however doesn't prevent a
        more lenient handling of this scenario.

        if the concurrent modifications are non-conflicting and trivial the changes could
        be silently merged in session1's transient state of node /a.

        examples for trivial non-conflicing changes:
        - s1 adds child node a, s2 removes child node b
        - s1 adds child node a, s2 adds child node b
        - s1 adds child node a, s2 adds mixin type

        examples for non-trivial and/or conflicing changes:
        - s1 adds child node a, s2 removes child node a
        - s1 adds sns child node a (-> a[3]), s2 removes sns child node a[1]
        - s1 removes sns child node a[2], s2 reorders child nodes affecting sns nodes a

        consider the following scenario:
        - session1 modifies node /a by adding a child node b
        - session2 modifies node /a by adding a child node c
        - session2 saves its changes
        - session1 tries to save its changes which results in a InvalidItemStateException

        this behavior is in accordance with the spec. the spec however doesn't prevent a
        more lenient handling of this scenario.

        if the concurrent modifications are non-conflicting and trivial the changes could
        be silently merged in session1's transient state of node /a.

        examples for trivial non-conflicting changes:
        - s1 adds child node a, s2 removes child node b
        - s1 adds child node a, s2 adds child node b
        - s1 adds child node a, s2 adds mixin type

        examples for non-trivial and/or conflicting changes:
        - s1 removes child node a, s2 removes child node a
        - s1 adds child node a, s2 adds child node a
        - s1 adds sns child node a (-> a[3]), s2 adds sns child node a (-> a[3])
        - s1 adds sns child node a (-> a[3]), s2 removes sns child node a[1]
        - s1 removes sns child node a[2], s2 reorders child nodes affecting sns nodes a

        Stefan Guggisberg made changes -
        Fix Version/s 1.1.1 [ 12312099 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Jukka Zitting made changes -
        Fix Version/s 1.2 [ 12312100 ]
        Fix Version/s 1.1.1 [ 12312099 ]
        Jukka Zitting made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Jukka Zitting made changes -
        Workflow jira [ 12386140 ] no-reopen-closed, patch-avail [ 12469183 ]

          People

          • Assignee:
            Stefan Guggisberg
            Reporter:
            Stefan Guggisberg
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development