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. > > -Flavio > >> -----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. >> >> -- >> James >> ------- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://open.iona.com > > -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
