On Tue, Apr 6, 2010 at 11:03 AM, Tatu Saloranta <tsalora...@gmail.com>wrote:
> 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). > I'd probably put it in core. Or at least put some more generic support for this sort of conflict resolution in core. I'm looking forward to seeing Digg's patch for this stuff. Mike
