Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.216.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=Mv4CMLKSZ+hXokKmk6xbbY1jfOw2iQvAAuvd+c7onekgazBNtktm8HYsJynfR628Gs
         2tnN+rbR1spC07NYd7VqrrbogC+MD8wE5/bmrnVMedBRiE3nrzxRzg/1CCs1xuURpDmi
         xjqSbHqpsmIX36ObsWnbM0kHvtah3t6NljD5M=
MIME-Version: 1.0
In-Reply-To: <8bc75ecf1002250007l7f21137fm65c16bb33b649e8@mail.gmail.com>
References: <8bc75ecf1002240340r55dc6bd2v5579f89105045506@mail.gmail.com>
	<b54edc3a1002241021t2ec3ca7i9505dbab6bb613a8@mail.gmail.com>
	<8bc75ecf1002241110q3ab10226v5c0a6d7e7b447cee@mail.gmail.com>
	<c7d45fc71002241435kafeaa79t763bb0df66330b14@mail.gmail.com>
	<8bc75ecf1002250007l7f21137fm65c16bb33b649e8@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Thu, 25 Feb 2010 11:09:13 -0800
Message-ID: <c7d45fc71002251109x24fac53by4a7769661bf5954d@mail.gmail.com>
Subject: Re: is there a good pattern for leases ?
To: zookeeper-user@hadoop.apache.org
Content-Type: multipart/alternative; boundary=001636920825e81ba10480718593

--001636920825e81ba10480718593
Content-Type: text/plain; charset=UTF-8

That is one of the strengths of ZK.  Your client would do this:

1) create node, if success client has lock
2) get current node (you get the current version when you do this), if lease
is current and ours, we have the lock, if lease is current and not ours, we
have failed to get the lock
3) try to overwrite node+version from step 2 with our lease claim, if
success, client has the lock
4) if failure in step (3), somebody else jumped ahead of us and updated the
document between steps 2 and 3.  They therefore have the lease or it was the
GC who did it.
5) client has failed to get the lock.  We could repeat step 1 here if we
suspect the GC caused our lossage, but I think that would be of vanishingly
small benefit.

Steps 1, 2 and 3 are not atomic, but they are guaranteed to either get the
lock correctly or fail.  The only surprise waiting for you is in step 3 if
you get a connection loss event between sending the update and getting
confirmation of the update.  That can be recovered after the connection is
automatically restored by going back to step 2.

On Thu, Feb 25, 2010 at 12:07 AM, Martin Waite <waite.134@googlemail.com>wrote:

> I cannot see how clients could safely inspect a node and overwrite the
> expiry time if it had expired.  That would involve multiple steps, and so
> not be atomic.
>

--001636920825e81ba10480718593--