Many thanks for the clear and concise explanation! I'll check out the slides.
Brian On Fri, Jul 19, 2013 at 11:29 AM, Ben Bangert <[email protected]> wrote: > On Jul 19, 2013, at 5:59 AM, Brian Tarbox <[email protected]> wrote: > > > Can you say more about this? We use Zookeeper to manage a large set of > > "work units" which are selected, locked, processed by EC2 worker > > computers...which then do work on and with Cassandra data. > > Sure, there's two parts to it. First, holding a lock external to Cassandra > itself has its own issue. This is because while you might be able to > guarantee that only one person is doing something with Cassandra, short of > using CL.ALL, there's no way to fully ensure that two people don't stomp on > updates. If you use CL.QUORUM, its still possible that a node could be > holding hints, client releases ZK lock, another client gets the lock, does > a read and if timed poorly will not see the prior change. > > Cassandra's CAS operation properly deals with this since its handled > inside Cassandra itself. > > Jonathan Ellis went over why client locks don't work for Cassandra at the > Cassandra Summit, slides from his talk here: > http://www.slideshare.net/jbellis/cassandra-summit-2013-keynote > > He goes over CAS on slide 52-60. > > Cheers, > Ben -- http://about.me/BrianTarbox
