You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Stefan Guggisberg (JIRA)" <ji...@apache.org> on 2006/10/04 12:39:21 UTC

[jira] Updated: (JCR-584) Improve handling of concurrent node modifications

     [ http://issues.apache.org/jira/browse/JCR-584?page=all ]

Stefan Guggisberg updated JCR-584:
----------------------------------

    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



  was:
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




fixed typos and examples entry

> Improve handling of concurrent node modifications
> -------------------------------------------------
>
>                 Key: JCR-584
>                 URL: http://issues.apache.org/jira/browse/JCR-584
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: core
>            Reporter: Stefan Guggisberg
>         Assigned To: Stefan Guggisberg
>
> 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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira