From dev-return-8949-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Oct 04 09:08:04 2006 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 32423 invoked from network); 4 Oct 2006 09:08:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Oct 2006 09:08:03 -0000 Received: (qmail 41033 invoked by uid 500); 4 Oct 2006 09:08:01 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 41013 invoked by uid 500); 4 Oct 2006 09:08:01 -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 41004 invoked by uid 99); 4 Oct 2006 09:08:01 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Oct 2006 02:08:01 -0700 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received: from [209.237.227.198] ([209.237.227.198:33987] helo=brutus.apache.org) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id E3/72-00170-DE973254 for ; Wed, 04 Oct 2006 02:07:57 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 34F657142DA for ; Wed, 4 Oct 2006 02:07:21 -0700 (PDT) Message-ID: <24747114.1159952841211.JavaMail.root@brutus> Date: Wed, 4 Oct 2006 02:07:21 -0700 (PDT) From: "Stefan Guggisberg (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Created: (JCR-584) Improve handling of concurrent node modifications MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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-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 -- 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