From jackrabbit-dev-return-1712-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Thu Apr 14 15:25:10 2005 Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 96543 invoked from network); 14 Apr 2005 15:25:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Apr 2005 15:25:10 -0000 Received: (qmail 3530 invoked by uid 500); 14 Apr 2005 15:23:47 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 3337 invoked by uid 99); 14 Apr 2005 15:23:43 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of felix.roethenbacher@wyona.com designates 195.226.6.68 as permitted sender) Received: from mx1.wyona.com (HELO mx1.wyona.com) (195.226.6.68) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 14 Apr 2005 08:23:40 -0700 Received: from gate.wyona.com ([195.226.6.75] helo=[192.168.1.36]) by mx1.wyona.com with esmtp (Exim 3.35 #1 (Debian)) id 1DM6Bp-0006qC-00 for ; Thu, 14 Apr 2005 17:23:33 +0200 Message-ID: <425E8C5F.4070308@wyona.com> Date: Thu, 14 Apr 2005 17:29:35 +0200 From: =?ISO-8859-1?Q?Felix_R=F6thenbacher?= User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jackrabbit-dev@incubator.apache.org Subject: Re: Transaction and locks References: <425BBC07.1050807@wyona.com> <425BCB94.5020409@wyona.com> <425E6CA8.4080208@wyona.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi David David Nuescheler wrote: > hi felix, > > >>[1] begin >>[2] lock nA in sA >>[3] lock nB in sB >>[4] sA.save >>[5] sB.save >>[6] commit >>[1] start of transaction, enlist the two resources >>[2] Is a LockException thrown if node is locked already? >> As stated in the spec, the lock is not visible in >> other sessions, right? >>[4,5] save node changes for committing >>[6] commit changes: changes are made visible to >> other sessions. What happens, if another >> session sC successfully locked node nA between the >> execution of [4] and [6]? As Dominique mentioned, >> the prepare() method is currently a no-op and >> there is no possibility to prevent that node >> nB is locked (returns prepared ok) and node >> nA is not (LockException). It seems that >> the ACID property of this transaction is broken. > > > not only do i find this example highly unlikely (two sessions > against the same repository, within one transaction) and Ok, take two transactional resources, if you want, two different repositories (maybe that's more likely). > pointless (save() has no role in it at all, since lock is auto > saved) but to me it also confuses the point that you seem > to want go after. > > let me try to rephrase your example, how i understand > the above questions: > (which btw has nothing todo with xa but is just a general > transaction question) > > [1] begin sA > [2] lock sA, nX > [3] begin sC > [4] lock sC, nX > [5] commit sC > [6] commit sA > > what happens according to the spec is that in step [6] the commit > would fail and the transaction will be rolled back. When you commit the transaction, the transaction manager will call commit on both sA and sB. If sA fails to commit (and it will not fail until sA and sB are in prepared state because prepare() is a no-op at the moment) it is impossible to rollback the transaction as sA AND sB are both instructed to commit by the transaction manager. I hope you see my point now. For me, ACIDity seems very highly endangered. Regards, Felix > the current jackrabbit implementation is slightly different, however > ACID should never be endangered. > > maybe you can clarify your question for me... > > regards, > david >