Thanks for the clarification. I think it makes lots of sense for the
leader to write to some canonical place to advertise itself; if others
are interested in knowing if it is the leader
2008/7/18 Flavio Junqueira <[EMAIL PROTECTED]>:
> Hi James, the fact that the client's node has another node n ahead of it the
> in the sequence order doesn't mean that the owner of n is aware that it is
> the lock holder or the leader. This is because operations are propagated
> asynchronously. Also, a getChildren() doesn't guarantee that you have the
> latest list, and it is possible that another node is at the head of the
> ordered list of nodes at the moment you read the response of getChildren().
> This is because getChildren() will return the local state of one server,
> while the ensemble of servers is processing or have even already decided
> upon a change to the list.
> In the way I understand Jacob's suggestion, a leader client creates a
> separate node to acknowledge that it is actually aware that it is the
> leader, and so it is ready to perform the role of a leader.
>> -----Original Message-----
>> One thing confused me though; the last paragraph says...
>> This protocol guarantees that there is at any time only one node that
>> thinks it is the leader. But it does not disseminate information about
>> who is the leader. If you want everyone to know who is the leader, you
>> can have an additional Znode whose value is the name of the current
>> leader (or some identifying information on how to contact the leader,
>> etc.). Note that this cannot be done atomically, so by the time other
>> nodes find out who the leader is, the leadership may already have
>> passed on to a different node.
>> In the current implementation, WriteLock - each znode can know,
>> whenever it attempts to acquire the lock - if it didn't get the lock,
>> who the owner is. I guess this is only true momentarily the split
>> second that the acquire() method is called (i.e. the exact moment the
>> getChildren() is called and the lowest value is found). Or is there
>> some other subtle issue I'm not seeing?
>> I guess we could add a method to WriteLock - if folks wanted - a kinda
>> queryLeader() method where we just use the same algorithm to find who
>> the current leader is - if folks cared. Though am not sure how useful
>> knowing who the leader is :). Though I guess writing the leader's
>> identity to some canonical znode that any other znode can read
>> whenever it wishes is less risky and maybe simpler.
>> Open Source Integration
Open Source Integration