cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donal Zang <>
Subject Re: [SPAM] Fwd: Counter consistency - are counters idempotent?
Date Fri, 22 Jul 2011 16:27:56 GMT
On 22/07/2011 18:08, Yang wrote:
> btw, this "issue" of  not knowing whether a write is persisted or not
> when client reports error, is not limited to counters,  for regular
> columns, it's the same: if client reports write failure, the value may
> well be replicated to all replicas later.  this is even the same with
> all other systems: Zookeeper, Paxos, ultimately due to the FLP
> theoretical result of "no guarantee of consensus in async systems"
yes, but with regular columns, retry is OK, while counter is not.
> ---------- Forwarded message ----------
> From: Sylvain Lebresne<>
> Date: Fri, Jul 22, 2011 at 8:03 AM
> Subject: Re: Counter consistency - are counters idempotent?
> To:
> On Fri, Jul 22, 2011 at 4:52 PM, Kenny Yu<>  wrote:
>> As of Cassandra 0.8.1, are counter increments and decrements idempotent? If,
>> for example, a client sends an increment request and the increment occurs,
>> but the network subsequently fails and reports a failure to the client, will
>> Cassandra retry the increment (thus leading to an overcount and inconsistent
>> data)?
>> I have done some reading and I am getting conflicting sources about counter
>> consistency. In this source
>> (,
>> it states that counters now have the same consistency as regular
>> columns--does this imply that the above example will not lead to an
>> overcount?
> That email thread was arguably a bit imprecise with its use of the
> word 'consistency'
> but what it was talking about is really consistency level. That is, counter
> supports all the usual consistency levels (ONE, QUORUM, ALL, LOCAL_QUORUM,
> EACH_QUORUM) excepted ANY.
> Counter are still not idempotent. And just a small precision, if you
> get a TimeoutException,
> Cassandra never retry the increment on it's own (your sentence
> suggests it does),
> but you won't know in that case if the increment was persisted or not,
> and thus you
> won't know if you should retry or not. And yes, this is still a
> limitation of counters.
>> If counters are not idempotent, are there examples of effective uses of
>> counters that will prevent inconsistent counts?
>> Thank you for your help.

Donal Zang
Computing Center, IHEP
19B YuquanLu, Shijingshan District,Beijing, 100049
86 010 8823 6018

View raw message