incubator-cassandra-user mailing list archives

On Wed, Feb 23, 2011 at 3:32 AM, Oleg Anastasyev <oleganas@gmail.com> wrote:
>> Basically: vector clocks tell you there was a conflict, but not how to
>> resolve it (that is, you simply don't have enough information to
>> resolve it even if you push that back to the client a la Dynamo).
>> What dynamo-like systems mostly VC for is the trivial case of "client
>> X updated field 1, client Y updated field 2, so I can resolve that
>> into a merged value containing both updates." But Cassandra already
>> handles that by splitting the row up into column-per-field, so VC
>> doesn't add anything for us.
>
> Still, vector clocks are very useful in read-modify-update scenarios. In these
> scenarios cassandra requies external pessimistic locking servers, which makes
> cassandra almost unusable for these scenarios, because of introduced latency,
> especially when you have low concurrency for a single column, where optimistic
> locking is a perfect fit.
>From the article I linked:
"But wait, some might say, you can avoid all this by using vectors in
a different way – to prevent update conflicts by issuing conditional
writes which specify a version (vector) and only succeed if that
version is still current. Sorry, but no, or at least not generally. In
a partition-tolerant system, nodes on each side of a partition may
simultaneously accept conflicting writes against the same initial
version, and you’ll still have to resolve the conflict when you
resolve the partition."
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com