On Mon, Apr 5, 2010 at 1:35 PM, Mike Malone <m...@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
