Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 357F391F4 for ; Wed, 30 May 2012 09:44:48 +0000 (UTC) Received: (qmail 46396 invoked by uid 500); 30 May 2012 09:44:46 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 45855 invoked by uid 500); 30 May 2012 09:44:41 -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 45812 invoked by uid 99); 30 May 2012 09:44:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 May 2012 09:44:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of the.wa.syndrome@gmail.com designates 209.85.161.172 as permitted sender) Received: from [209.85.161.172] (HELO mail-gg0-f172.google.com) (209.85.161.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 May 2012 09:44:33 +0000 Received: by ggnc4 with SMTP id c4so3843078ggn.31 for ; Wed, 30 May 2012 02:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5kSWaowzsjFGiqlXrtyCrufEFU/G87mv0YOPAK5X/F4=; b=W5WU9vw/Z09fdnUcIM2AiMvnMkFgS4/xKGec3LOryHkLNG5gk1xX2Y+YLOl+k2nsF1 WkYLbeV2yrBBE2HVGGKdTPCCvnbNcRHiMFySgInB11C8ChqCyN6e7qhgTT0+EqpeuWAN J2iWZKOxmO1tbWYnrj74KwORUsBNWkktiNmu1bm5wMNzSaalYMDOmBtLLhWlviYQwD9r pOxIzxl3Nobxkdipi+FeCMaN27ZjYF3kjBmlcwtFtNa8bdKoAV+NeuMQrGuH2T4Hyrq6 1GNlrWseghYKcH40y4B5WPnRy1KtD8G+GzJaIUVu/NRkwXa+X00QM6tRSRUqF38r9rGJ sxEg== MIME-Version: 1.0 Received: by 10.43.47.10 with SMTP id uq10mr4754174icb.15.1338371051961; Wed, 30 May 2012 02:44:11 -0700 (PDT) Received: by 10.64.17.161 with HTTP; Wed, 30 May 2012 02:44:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 May 2012 10:44:11 +0100 Message-ID: Subject: Re: Concurrency Control From: =?UTF-8?Q?Filipe_Gon=C3=A7alves?= To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=bcaec5299a31213d7504c13dcb0b --bcaec5299a31213d7504c13dcb0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's the timestamps provided in the columns that do concurrency control/conflict resolution. Basically, the newer timestamp wins. For counters I think there is no such mechanism (i.e. counter updates are not idempotent). >From https://wiki.apache.org/cassandra/DataModel : All values are supplied by the client, including the 'timestamp'. This > means that clocks on the clients should be synchronized (in the Cassandra > server environment is useful also), as these timestamps are used for > conflict resolution. In many cases the 'timestamp' is not used in client > applications, and it becomes convenient to think of a column as a > name/value pair. For the remainder of this document, 'timestamps' will be > elided for readability. It is also worth noting the name and value are > binary values, although in many applications they are UTF8 serialized > strings. > Timestamps can be anything you like, but microseconds since 1970 is a > convention. Whatever you use, it must be consistent across the applicatio= n, > otherwise earlier changes may overwrite newer ones. 2012/5/28 Helen > Hi, > what kind of Concurrency Control Method is used in Cassandra? I found out > so far > that it's not done with the MVCC Method and that no vector clocks are > being used. > Thanks Helen > > --=20 Filipe Gon=C3=A7alves --bcaec5299a31213d7504c13dcb0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's the timestamps provided in the columns that do concurrency co= ntrol/conflict resolution. Basically, the newer timestamp wins.
F= or counters I think there is no such mechanism (i.e. counter updates are no= t idempotent).

From=C2=A0https://wiki.apache.org/cassandra/DataModel=C2=A0:

=
All values are supplied by the client, including the 'timestamp'. T= his means that clocks on the clients should be synchronized (in the Cassand= ra server environment is useful also), as these timestamps are used for con= flict resolution. In many cases the 'timestamp' is not used in clie= nt applications, and it becomes convenient to think of a column as a name/v= alue pair. For the remainder of this document, 'timestamps' will be= elided for readability. It is also worth noting the name and value are bin= ary values, although in many applications they are UTF8 serialized strings.=
Timestamps can be anything you like, but microseconds since 1970 is a conve= ntion. Whatever you use, it must be consistent across the application, othe= rwise earlier changes may overwrite newer ones.


2012/5/28 Helen <live42day@gmx.ch>
Hi,
what kind of Concurrency Control Method is used in Cassandra? I found out s= o far
that it's not done with the MVCC Method and that no vector clocks are b= eing used.
Thanks Helen




--
Filipe Gon= =C3=A7alves
--bcaec5299a31213d7504c13dcb0b--