From user-return-10055-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Thu Oct 21 18:59:02 2010 Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 28589 invoked from network); 21 Oct 2010 18:59:01 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Oct 2010 18:59:01 -0000 Received: (qmail 93805 invoked by uid 500); 21 Oct 2010 18:58:59 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 93786 invoked by uid 500); 21 Oct 2010 18:58:59 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 93778 invoked by uid 99); 21 Oct 2010 18:58:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Oct 2010 18:58:59 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jverstry@gmail.com designates 209.85.215.172 as permitted sender) Received: from [209.85.215.172] (HELO mail-ey0-f172.google.com) (209.85.215.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Oct 2010 18:58:52 +0000 Received: by eyd10 with SMTP id 10so380787eyd.31 for ; Thu, 21 Oct 2010 11:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NLHLpBCpWPSGsTJ8KPVCn7WBXe28AqvBe64zqLHPAzM=; b=JgldPNGjASgbDTokYLXGXVF54b/BuBFdTWqUWSJB/8dSWEPWVPSj4wG7J7/qzkD28O x0q90EQ7xywqXzfy8EXa/thx1Z+cW/86hU3/sKpcBNkZM3zSR56obTVZTSY2DuYXK37N nwDv1uUYwmkcj/sUsTdx1KI+457RoChIGe4LA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=RTKkP0Tk8xv0u3xN3qTEgFwX6TT/j1QXCQqHdGLbTWV0klQsZnca0xAkHFWIuYroa1 csoI4EthpR1s8TLKmgZiOXvgrByab7JfrhYZQA3R+TZhcxyuRWxkMSLnwRP2JFIDGujd 91qTL9PGVYeqDjDyTX+tNEwG07err9QRpO6uE= Received: by 10.213.25.134 with SMTP id z6mr2192838ebb.12.1287687510955; Thu, 21 Oct 2010 11:58:30 -0700 (PDT) Received: from [192.168.1.64] ([92.65.215.33]) by mx.google.com with ESMTPS id q58sm2142090eeh.21.2010.10.21.11.58.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Oct 2010 11:58:29 -0700 (PDT) Message-ID: <4CC08D51.9080405@gmail.com> Date: Thu, 21 Oct 2010 20:58:25 +0200 From: =?UTF-8?B?SsOpcsO0bWUgVmVyc3RyeW5nZQ==?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: user@cassandra.apache.org CC: Peter Schuller , Jonathan Ellis Subject: Re: What happens if there is a collision? References: <4CBF99A8.7060304@dawningstreams.com> <4CBFB04E.6090406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 21/10/2010 20:03, Peter Schuller wrote: >> My question is: is node E notified that it lost the battle against A? If yes >> how? >> >> If not, then it means that, although writes are atomic, they would not be >> deterministic. Node E would have to verify that its write was successful... > Quorom is not really a special case in that sense; it just tells how > many nodes must ack the operation. The conflict resolution of columns > proceed as usual and data replicate as usual. Node E would do the same > conflict resolution as other nodes whenever it sees the write, > regardless of that was because it was in the original chosen quorom > set, or it was given the right a bit later in the background, or it > happened during anti-entropy etc. OK. Thanks for your answer. From an email exchange I had with Jonathan, all this means that one should re-read its writes with quorum to make sure they have not been overriden by timestamp-tie conflicts. I suggested to send feedback to writting node (in the ACK) when such timestamps-tie conflict happen. This would avoid having to double-check all writes for timestamp-tie conflicts. If multiple applications write to the same ColumnFamily/Tables, this double-check is a must (unless a separate locking mecanism is implemented, which would be more heavy). Jérôme