On Tue, Apr 6, 2010 at 8:45 AM, Mike Malone <m...@simplegeo.com> wrote: >> 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.
I doubt there is any simple and elegant solution -- if there was, it would have been invented in 50s if there was. :-) Given this, yes, something along these lines sounds realistic. It also sounds like implementation would greatly benefit (if not require) foundational support from core, as opposed to being done outside of Cassandra (which I understand you are suggesting). I wasn't sure if the idea was to try to do this completely separate (aside from vector clock support). -+ Tatu +-
