cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Malone <>
Subject Re: How do vector clocks and conflicts work?
Date Tue, 06 Apr 2010 15:45:04 GMT
> As long as the conflict resolver knows that two writers each tried to
> increment, then it can increment twice. The conflict resolver must know
> about the semantics of "increment" or "decrement" or "string append" or
> "binary patch" or whatever other merge strategy you choose. You'll register
> your "strategy" with Cassandra and it will apply it. Presumably it will also
> maintain enough context about what you were trying to accomplish to allow
> the merge strategy plugin to do it properly.
>> That is to say, my understanding was that vector clocks would be
>> required but not sufficient for reconciliation of concurrent value
>> updates.
The way I envisioned "eventually consistent counters" working would require
something slightly more sophisticated... but not too bad. As incr/decr
operations happen on distributed nodes, each node would keep a (vector
clock, delta) tuple for that node's local changes. When a client fetched the
value of the counter the vector clock deltas and the reconciled count would
be combined into a single result. Similarly, when a replication /
hinted-handoff / read-repair reconciliation occurred the counts would be
merged into a single (vector clock, count) tuple.

Maybe there's a more elegant solution, but that's how I had been thinking
about this particular problem.


View raw message