Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 7033 invoked from network); 30 Sep 2010 17:16:59 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 30 Sep 2010 17:16:59 -0000 Received: (qmail 31536 invoked by uid 500); 30 Sep 2010 17:16:59 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 31489 invoked by uid 500); 30 Sep 2010 17:16:58 -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 31480 invoked by uid 99); 30 Sep 2010 17:16:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Sep 2010 17:16:58 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [131.234.142.9] (HELO mail.uni-paderborn.de) (131.234.142.9) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Sep 2010 17:16:49 +0000 Received: from pdbn-4db11d8e.pool.mediaways.net ([77.177.29.142] helo=[192.168.178.2]) by mail.uni-paderborn.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69 spheron) id 1P1Mk7-0008Ra-IQ for users@jackrabbit.apache.org; Thu, 30 Sep 2010 19:16:28 +0200 Message-ID: <4CA4C5E8.4090206@mail.upb.de> Date: Thu, 30 Sep 2010 19:16:24 +0200 From: Dominik Klaholt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.12) Gecko/20100914 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: users@jackrabbit.apache.org Subject: Locks and Transactions - JCR spec example Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-IMT-Spam-Score: 0.0 () X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.9.30.170615 X-IMT-Authenticated-Sender: uid=dokla,ou=People,o=upb,c=de X-Virus-Checked: Checked by ClamAV on apache.org Hello, has anyone else stumbled across the JCR spec example on how to avoid lost updates (page 240): begin lock commit begin do A save do B save unlock commit The strange thing about this example is that the unlock does not have an effect if the transaction rolls back - so whatever is locked stays locked. Is there any way to ensure that the unlock happens no matter whether the transaction commits or rolls back (or is the example just a little confusing)? Thanks Dominik