From users-return-10043-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Mon Jan 05 01:55:47 2009 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 1943 invoked from network); 5 Jan 2009 01:55:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Jan 2009 01:55:47 -0000 Received: (qmail 14355 invoked by uid 500); 5 Jan 2009 01:55:45 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 14334 invoked by uid 500); 5 Jan 2009 01:55:45 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 14323 invoked by uid 99); 5 Jan 2009 01:55:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Jan 2009 17:55:45 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dworyu@nhncorp.com designates 121.156.63.221 as permitted sender) Received: from [121.156.63.221] (HELO nhn545.nhncorp.com) (121.156.63.221) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jan 2009 01:55:39 +0000 Received: from mexkrf01.all.nhncorp.com ([10.31.36.67]) by nhn545.nhncorp.com (8.13.8/8.13.8) with ESMTP id n051tGIk002216 for ; Mon, 5 Jan 2009 10:55:17 +0900 Received: from MEXKR03.all.nhncorp.com ([10.31.36.57]) by mexkrf01.all.nhncorp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jan 2009 10:55:16 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Subject: RE: concurrent writes Date: Mon, 5 Jan 2009 10:55:21 +0900 Message-ID: <69D47EC63718CC41A03C894F642858646A4B79@MEXKR03.all.nhncorp.com> In-Reply-To: <6c59d89a0901041107k7b92deeco34885d41c8949b2b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: concurrent writes Thread-Index: Aclun8attteVaVHiQwegxxwTmwrTlAAN+x8g References: <6c59d89a0901041107k7b92deeco34885d41c8949b2b@mail.gmail.com> From: =?ks_c_5601-1987?B?t/m067/4?= To: X-OriginalArrivalTime: 05 Jan 2009 01:55:16.0384 (UTC) FILETIME=[A7CAB200:01C96ED8] X-Virus-Checked: Checked by ClamAV on apache.org Hi,=20 In that case, if you want to prevent B's writing, A has to lock the node = before writing. I don't think B could receive any notification of changes by A. And without lock mechanism, your assumptions are correct. won -----Original Message----- From: tcurdt@vafer.org [mailto:tcurdt@vafer.org] On Behalf Of Torsten = Curdt Sent: Monday, January 05, 2009 4:08 AM To: users@jackrabbit.apache.org Subject: concurrent writes I am wondering how "concurrent" writes are handled with jcr/jackrabbit. While the spec (4.1.3.2 Transient Storage in the Session) does answer some of the questions I was wondering about some of the details. Let's say I have two people A and B editing a node from a JCR repository. Both hold a reference to the node concurrently in different sessions. Both modify some properties. Now A saves his session, then B saves his session. IIUC the repository would now show the state of B's session as B was essentially last. Assuming the node has mixin mix:versionable I would expect to revisions like 1 original 2 from A 3 from B Are these assumptions correct? Would there be any sign/notification (exception/return code) for B that the node he wants to write to was changed by A? cheers -- Torsten