From dev-return-33363-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Thu Dec 1 15:20:55 2011 Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1AE207F28 for ; Thu, 1 Dec 2011 15:20:55 +0000 (UTC) Received: (qmail 13697 invoked by uid 500); 1 Dec 2011 15:20:54 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 13646 invoked by uid 500); 1 Dec 2011 15:20:54 -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 13639 invoked by uid 99); 1 Dec 2011 15:20:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Dec 2011 15:20:54 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.18.1.208] (HELO exprod6og107.obsmtp.com) (64.18.1.208) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Dec 2011 15:20:43 +0000 Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKTtebNt5YW13jlMjgFHhtvplvCK/fjD27@postini.com; Thu, 01 Dec 2011 07:20:23 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pB1FIa8G017381 for ; Thu, 1 Dec 2011 07:18:36 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id pB1FKCRI023569 for ; Thu, 1 Dec 2011 07:20:19 -0800 (PST) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 1 Dec 2011 07:20:17 -0800 Received: from susi.local (10.136.169.101) by eurhub01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.192.1; Thu, 1 Dec 2011 15:20:15 +0000 Message-ID: <4ED79B2E.6020007@apache.org> Date: Thu, 1 Dec 2011 15:20:14 +0000 From: =?ISO-8859-1?Q?Michael_D=FCrig?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Subject: Re: [jr3 microkernel] Write skew References: <4ED63BEE.6010904@apache.org> <4ED751DC.8070606@apache.org> <4ED76F55.3030001@apache.org> <4ED7806E.5010402@apache.org> <4ED79707.9020304@apache.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 1.12.11 15:10, Jukka Zitting wrote: >>> If I understand the paper correctly, also this approach requires >>> synchronization to establish the serialization order of transactions. >> >> No I don't think so. What it does is, it cancels problematic transactions. >> Detecting these requires finding certain read-write conflicts between >> transactions. > > But if there are two concurrent transactions, the commit of the other > one needs to wait until the first one has been processed before it can > complete the check against conflicts. Otherwise how can a conflicting > commit be made to fail? > I see, that's right. Unless the other transaction has access to the operations of the first transaction. In that case - and if it decides to abort due to a conflict and later the first also decides to abort - the other transaction would have aborted unnecessarily. That shouldn't hurt too much though. Michael