UPDATE foo SET x = x + 1 is inherently not idempotent. Thus, client-based idempotence is not in fact a design goal.
What 2.1 achieves is making commitlog replay idempotent. On Fri, Oct 10, 2014 at 3:44 AM, Rajath Subramanyam <rajat...@gmail.com> wrote: > Hi Aleksey, > > Thanks for the response. I read through several JIRAs ( CASSANDRA-1072, > CASSANDRA-2495, CASSANDRA-4775, CASSANDRA-6504, CASSANDRA-6506). I would > appreciate if you can clarify my understanding of the current state of art. > > I understand that the earlier design of having local shards, remote shards > and logging only deltas for local shards provided good latency but suffered > inconsistencies due to replays not being idempotent. Was this primarily > lack of internal idempotent updates (replica-replica) or due to lack > external idempotent updates (client-coordinator) ? Also, I have an > additional question about the state of counters before CASSANDRA-6504 (or > Counters 1.0 if you like). Does the client submit > CounterUpdate<counter-name, value, timestamp> ? During the retry is the > same CounterUpdate<counter-name, value, timestamp> submitted again > identically as the original attempt ? When the coordinator (if it is one of > the replica) OR the leader does a write propagation to the other replicas > does it include the same CounterUpdate<counter-name, value, timestamp> ? > Essentially, my question is: Can we identify each counter update from a > client uniquely ? and does the retry use the same unique id ? > > Also post the implementation of CASSANDRA-6504 (or Counters 2.0 design) I > understand that local and remote shards have been replaced by global shards > and now counters follow a lock-read-write-unlock-replicate model. Does this > guarantee that retries from clients are still idempotent ? Also, in > Counters 2.0, is the CounterUpdate sent by the client an unique id ? > > I would appreciate your clarification on this. > > Thank you ! > > Regards, > Rajath > > > ------------------------ > Rajath Subramanyam > > > On Mon, Oct 6, 2014 at 3:38 PM, Aleksey Yeschenko <alek...@apache.org> > wrote: > > > No, there are no unique ids per increment. That was one of the ideas > > suggested in https://issues.apache.org/jira/browse/CASSANDRA-4775, but > > ultimately declined. > > > > Read that ticket, and the one linked to it, for details. > > > > -- > > AY > > > > On October 6, 2014 at 10:20:05 PM, Rajath Subramanyam ( > rajat...@gmail.com) > > wrote: > > > > Hi Cassandra developers, > > > > I am working on a project to make counter updates idempotent. I read that > > via CASSANDRA-1546 assigns unique marker ids to counter updates in 0.7.1. > > Does this unique marker id hold true in the later versions too ? Or at > > least in 0.8.1 ? > > > > Please let me know. > > > > Thank you ! > > > > Regards, > > Rajath > > ------------------------ > > Rajath Subramanyam > > > > > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
