incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Prescod <p...@ayogo.com>
Subject Re: Memcached protocol?
Date Mon, 05 Apr 2010 20:46:03 GMT
On Mon, Apr 5, 2010 at 1:35 PM, Mike Malone <mike@simplegeo.com> wrote:
>> That's useful information Mike. I am a bit curious about what the most
>> common use cases are for atomic increment/decrement. I'm familiar with
>> atomic add as a sort of locking mechanism.
>
> They're useful for caching denormalized counts of things. Especially things
> that change rapidly. Instead of invalidating the counter whenever an event
> occurs that would incr/decr the counter, you can incr/decr the cached count
> too.

Do you think that a future cassandra increment/decrement would be
incompatible with those use cases?

It seems to me that in that use case, an eventually consistent counter
is as useful as any other eventually consistent datum. In other words,
there is no problem incrementing from 12 to 13 and getting back 15 as
the return value (due to coinciding increments). 15 is the current
correct value. It's arguably more correct then a memcached value which
other processes are trying to update but cannot because of locking.
Benjamin seemed to think that there were applications that depended on
the result always being 13.

I'm trying to understand whether a future cassandra "eventually
consistent" increment/decrement feature based on vector clocks would
have semantics that are incompatible with most deployed uses of
memcached increment/decrement.

 Paul Prescod

Mime
View raw message