Jonathan Ellis <jbellis <at> gmail.com> 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.
