> > 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. Mike
