RE: javadoc for the Write Lock / Leader Election
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
Re: javadoc for the Write Lock / Leader Election
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
