incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gabriele renzi <rff....@gmail.com>
Subject Re: How do vector clocks and conflicts work?
Date Tue, 06 Apr 2010 19:28:01 GMT
On Tue, Apr 6, 2010 at 9:11 AM, Paul Prescod <prescod@gmail.com> wrote:
> This may be the blind leading the blind...
> On Mon, Apr 5, 2010 at 11:54 PM, Tatu Saloranta <tsaloranta@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.

as long as operations are commutative, isn't the conflict resolution
simply "apply all" ? A large number of useful operations can be
implemented this way (numeric incr/decr, set ops etc)

Mime
View raw message