This may be the blind leading the blind... On Mon, Apr 5, 2010 at 11:54 PM, Tatu Saloranta <tsalora...@gmail.com>wrote: >...
> I think the key is that this is not automatic -- there is no general > mechanism for aggregating distinct modifications. Point being that you > could choose one amongst right answers, but not what to do with > concurrent modifications. So what is done instead is have > application-specific resolution strategy which makes use of semantics > of operations, to know how to combine such concurrent modifications > into "correct" answer. I agree with all of that. > I don't know if this is trivial for case of > counter increments: especially since two concurrent increments give > same new value; yet correct combined result would be one higher (both > used base, added one). > 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. > I agree. They are necessary, but not sufficient. The other half is the "merge strategy plugin" thing, which is analogous to custom comparators in Cassandra today. In CASSANDRA-580, Pedro Gomes talks about the plugins like this: "I suppose for the beginning of the discussion that some sort of interface will be implemented to allow pluggable logic to be added to the server, personalized scripts were an idea, I have heard. " Kevin Kakugawa replies that they'll just use Java class libraries as a first pass. Paul Prescod
