cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Does Cassandra use vector clocks
Date Wed, 23 Feb 2011 14:20:23 GMT
On Wed, Feb 23, 2011 at 3:32 AM, Oleg Anastasyev <> 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

View raw message