Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jmischo@quagility.com
 designates 216.154.210.211 as permitted sender)
Message-Id: <542C4F67-FD4D-475D-A459-4D79DF194414@quagility.com>
From: Jonathan Mischo <jmischo@quagility.com>
To: cassandra-user@incubator.apache.org
In-Reply-To: <1257371829.656427824@192.168.1.71>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Incr/Decr Counters in Cassandra
Date: Wed, 4 Nov 2009 16:10:39 -0600
References: <6E415F02-B17C-4559-94AA-D82903DD113C@digg.com>
 <1257371829.656427824@192.168.1.71>

This is actually why retrieve and incr/decr ops are so important...you  
still have your consistency level, and that drives how accurate the  
returned data is, but since you're sending an operation, not  
alteration of the data, there's no conflict, you just have to make  
sure you don't miss an op.  In this case, though, there'd have to be  
an additional mechanism for the commit log, so if there was a  
conflict, read repair would be able to pull a list of ops since the  
last agreement, and figure out what the right value is.  Highly active  
counters don't work in eventually consistent models if you rely on the  
client.

On Nov 4, 2009, at 3:57 PM, Stu Hood wrote:

> This type of problem is one of the primary examples of something  
> that should be handled by pluggable/client-side conflict resolution  
> in an eventually consistent system. Currently, all conflicts in  
> Cassandra are handled with "highest timestamp wins"
>
> Rather than attempting to add atomic operations, I think we should  
> support one of the following in the (near) future:
> 1) Client side resolution
>   * When two writes conflict (ex: two clients simultaneously read  
> the counter at "2", and then write it at "3"), the next client  
> receives a callback with the old value and both new values, and can  
> then do application specific resolution (ex: both clients  
> incremented by "1", so use "4").
> 2) Pluggable resolution
>   * When two writes conflict, pluggable logic on the server side  
> decides how to merge the writes. You could implement the same  
> algorithm used in the example above, but the code would have to  
> exist on the server side.
>
> Personally, I think (1) is the better approach, and for backwards  
> compatibility in the API, you could make the resolution optional.
>
>
> -----Original Message-----
> From: "Chris Goffinet" <goffinet@digg.com>
> Sent: Wednesday, November 4, 2009 3:32pm
> To: cassandra-user@incubator.apache.org
> Cc: cassandra-dev@incubator.apache.org
> Subject: Incr/Decr Counters in Cassandra
>
> Hey,
>
> At Digg we've been thinking about counters in Cassandra. In a lot of
> our use cases we need this type of support from a distributed storage
> system. Anyone else out there who has such needs as well? Zookeeper
> actually has such support and we might use that if we can't get the
> support in Cassandra.
>
> ---
> Chris Goffinet
> goffinet@digg.com
>
>
>
>
>
>
>
>