Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (nike.apache.org: domain of briantarbox@gmail.com
 designates 209.85.215.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <AD8F1640-999C-4B4A-8F6D-FE5287D247DF@groovie.org>
References: 
 <CAK9uNUWxAFGWxm_jqNDGLcqDjaFn8XCWHjg7y_TADwNCenZ5Bg@mail.gmail.com>
	<CAKF1A=t4FpSNLUa2YzryU59oBF+vHceVZ6czBZVz61WL4MLO2g@mail.gmail.com>
	<5883C72959AF6546B303F6958D47FF040590389A@NDA-HCLT-MBS03.hclt.corp.hcl.in>
	<CAAE5aANTQXFEeT5ErjzJezx2bQYwU4kfhbRjhkc4qRJu+Z2jSQ@mail.gmail.com>
	<A3896F15-F9FD-4536-880C-E6BDC9A4FB12@jordanzimmerman.com>
	<5883C72959AF6546B303F6958D47FF04059039B1@NDA-HCLT-MBS03.hclt.corp.hcl.in>
	<9D3BF7B9-6399-4EE3-AC49-77D4EA5145E4@groovie.org>
	<CAP8NC13GbDJQvG88568XEqR0VzN6Kps_VFG3tSMcu7=v8z=35g@mail.gmail.com>
	<AD8F1640-999C-4B4A-8F6D-FE5287D247DF@groovie.org>
Date: Fri, 19 Jul 2013 12:15:13 -0400
Message-ID: 
 <CAP8NC13+=HhPcLsWOiwuE0QDvuHdQk4jQ6LDpMwRVg3dYPT_vg@mail.gmail.com>
Subject: Re: Use zookeeper with Cassandra
From: Brian Tarbox <briantarbox@gmail.com>
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=089e0160b432aeb73104e1dfa1e3

--089e0160b432aeb73104e1dfa1e3
Content-Type: text/plain; charset=ISO-8859-1

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 <ben@groovie.org> wrote:

> On Jul 19, 2013, at 5:59 AM, Brian Tarbox <briantarbox@gmail.com> 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

--089e0160b432aeb73104e1dfa1e3--