Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 94043 invoked from network); 16 Nov 2006 13:58:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Nov 2006 13:58:15 -0000 Received: (qmail 55731 invoked by uid 500); 16 Nov 2006 13:58:13 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 55700 invoked by uid 500); 16 Nov 2006 13:58:13 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 55673 invoked by uid 99); 16 Nov 2006 13:58:13 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Nov 2006 05:58:13 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Nov 2006 05:58:02 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id E76F6714324 for ; Thu, 16 Nov 2006 05:57:41 -0800 (PST) Message-ID: <32951113.1163685461925.JavaMail.jira@brutus> Date: Thu, 16 Nov 2006 05:57:41 -0800 (PST) From: "Jukka Zitting (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Updated: (JCR-584) Improve handling of concurrent node modifications In-Reply-To: <24747114.1159952841211.JavaMail.root@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ http://issues.apache.org/jira/browse/JCR-584?page=all ] Jukka Zitting updated JCR-584: ------------------------------ Fix Version/s: 1.2 (was: 1.1.1) > 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 > Fix For: 1.2 > > > 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