You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Arie Zilberstein <az...@salesforce.com> on 2013/09/11 10:40:10 UTC

Atomically setting a node's data while having leadership

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

Re: Atomically setting a node's data while having leadership

Posted by Arie Zilberstein <az...@salesforce.com>.
Yes, currently the path of the leader lock is pretty much inaccessible to
the user of the LeaderSelector (It's "hidden" in
LeaderSelector.mutex.threadData...).

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).

Thanks,
Arie


On Wed, Sep 11, 2013 at 7:09 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> 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 <az...@salesforce.com>
> 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
>
>

Re: Atomically setting a node's data while having leadership

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <az...@salesforce.com> 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