Return-Path: Delivered-To: apmail-cassandra-dev-archive@www.apache.org Received: (qmail 78776 invoked from network); 16 Aug 2010 13:30:23 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Aug 2010 13:30:23 -0000 Received: (qmail 54769 invoked by uid 500); 16 Aug 2010 13:30:23 -0000 Delivered-To: apmail-cassandra-dev-archive@cassandra.apache.org Received: (qmail 54406 invoked by uid 500); 16 Aug 2010 13:30:20 -0000 Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list dev@cassandra.apache.org Received: (qmail 54393 invoked by uid 99); 16 Aug 2010 13:30:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Aug 2010 13:30:19 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nick.telford@tweetmeme.com designates 74.125.82.172 as permitted sender) Received: from [74.125.82.172] (HELO mail-wy0-f172.google.com) (74.125.82.172) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Aug 2010 13:30:12 +0000 Received: by wyb40 with SMTP id 40so6139160wyb.31 for ; Mon, 16 Aug 2010 06:29:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.3.19 with SMTP id 19mr2514708weg.108.1281965391413; Mon, 16 Aug 2010 06:29:51 -0700 (PDT) Sender: nick.telford@tweetmeme.com Received: by 10.216.132.157 with HTTP; Mon, 16 Aug 2010 06:29:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Aug 2010 14:29:51 +0100 X-Google-Sender-Auth: JDw_vVfIvuBuW0P27BZFbYBCuyA Message-ID: Subject: Re: Locking in cassandra From: Nick Telford To: dev@cassandra.apache.org Content-Type: multipart/alternative; boundary=0016e64c165ac508ae048df0d341 --0016e64c165ac508ae048df0d341 Content-Type: text/plain; charset=ISO-8859-1 Hi Maifi, This is the expected behaviour for updating a value - the "newest" value always wins in the event of a conflict (e.g. after two partitions converge). Your use case is that of incrementing counters, which is not something that is easily solved in Cassandra at the moment. There are issues currently logged for counters (and version vectors, which are loosely related): - https://issues.apache.org/jira/browse/CASSANDRA-1072 - Increment Counters - https://issues.apache.org/jira/browse/CASSANDRA-580 - Version Vectors Also, this is really something for the user list (user@cassandra.apache.org) Regards, Nick --0016e64c165ac508ae048df0d341--