cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Anastastasyev <>
Subject Re: Does Cassandra use vector clocks
Date Wed, 23 Feb 2011 22:09:00 GMT
Jonathan Ellis <jbellis <at>> writes:

> IMO if you only get CL.ALL it's not superior enough to pessimistic
> locking to justify the complexity of adding it.
Yes, may be youre right, but CL.ALL is neccessary only to solve this problem in
a generic way. 

In some (most?) cases, conflicts detection, even on read/compaction stage is
enough. Such conflicts can be then resolved in non generic, app specific way
(eg, by specifying some ConflictResolver class on a per CF config). And for app
specific resolution, lower CLs are ok, because they dont require to detect
conflict during update operation.

For example, in our heavy loaded messaging cluster, only 0.015% of updates are
writing to the same column. Employing pessimistic locking for 100% of updates to
resolve that tiny percent of conflicts (and sighnifically raising latency of all
updates) looked like overkill, but all conflicts could be resolved in app
specific way.

It may be even more important to help ppl to diagnose, that conflicting updates
problem do exist in their appllication. Current cassanda's conflict resolution
silently ignores (and overwrites) conflicting updates, making this problem
hidden for prolonged time and, so, difficult to diagnose and fix at early stages
of development.

View raw message