On Wed, Feb 23, 2011 at 3:32 AM, Oleg Anastasyev <olega...@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
