On Tue, Apr 6, 2010 at 8:45 AM, Mike Malone <email@example.com
>> 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
> 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.