Dilip Kumar 2013-05-15, 16:28
Owen Kim 2013-05-15, 19:31
Jordan Zimmerman 2013-05-15, 19:33
Dilip Kumar 2013-05-15, 20:10
Ben Bangert 2013-07-19, 01:31
Brian Tarbox 2013-07-19, 12:59
Ben Bangert 2013-07-19, 15:29
Many thanks for the clear and concise explanation! I'll check out the
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:
> He goes over CAS on slide 52-60.