curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arie Zilberstein <>
Subject Re: Atomically setting a node's data while having leadership
Date Thu, 12 Sep 2013 07:09:22 GMT
Yes, currently the path of the leader lock is pretty much inaccessible to
the user of the LeaderSelector (It's "hidden" in

I think it would be a good addition to the library since some operations
must be done while making sure leadership is held. For example if your
leader just completed doing a bunch of work but lost leadership before
updating the ZooKeeper-stored shared state variable, then it should not be
allowed to update this variable (since another process may have acquired
leadership and already started working on the same bunch).


On Wed, Sep 11, 2013 at 7:09 PM, Jordan Zimmerman <> wrote:

> I think it could be done with a transaction. i.e.
>             client.inTransaction()
>                 .check().forPath("/leader/path/...")
>                     .and()
>                 .setData().forPath("/some/other/path...", data)
>                     .and()
>                 .commit()
> So, we'd need to either expose the path/name of the leader's lock ZNode or
> make this a method of LeaderSelector (and other lock-oriented recipes).
> -JZ
> On Sep 11, 2013, at 3:40 AM, Arie Zilberstein <>
> wrote:
> > Hi,
> >
> > I wonder if it is possible to achieve the following behavior: Assume a
> leader election scenario where a certain process has been elected as leader
> and its takeLeadership() method was called. Inside that method the process
> wishes to perform a Zookeeper operation, e.g., to set data in a node. But,
> the leader may receive a message saying to relinquish leadership
> immediately at any point in time. So the question is, is it possible to set
> this data while making sure that we're still the leader?
> > Can Curator support this sort of an atomic "test-and-set" operation?
> >
> > Thanks,
> > Arie

View raw message