zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: locking/leader election and dealing with session loss
Date Wed, 15 Jul 2015 19:01:53 GMT
I don’t see how there’s a chance of multiple writers. Assuming a reasonable session timeout:

* Client A gets the lock
* Client B watches Client A’s lock node
* Client A gets a network partition
* Client A will get a SysDisconnected before the session times out
* Client A must immediately assume it no longer has the lock
* Client A’s session times out
* Client A’s ephemeral node is deleted
* Client B’s watch fires
* Client B takes the lock
* Client A reconnects and gets SESSION_EXPIRED

Where’s the problem? This is how everyone uses ZooKeeper. There is 0 chance of multiple
writers in this scenario.

On July 15, 2015 at 1:56:37 PM, Vikas Mehta (vikasmehta@gmail.com) wrote:

Camille, I don't have a central message store/processor that can guarantee  
single writer (if I had one, it would reduce (still useful in reducing lock  
contention, etc) the need/value of using zookeeper) and hence I am trying to  
minimize the chances of multiple writers (more or less trying to guarantee  
this) while maximizing availability (not trying to solve CAP theorem), by  
solving some specific issues that affect availability.  

View this message in context: http://zookeeper-user.578899.n2.nabble.com/locking-leader-election-and-dealing-with-session-loss-tp7581277p7581284.html
Sent from the zookeeper-user mailing list archive at Nabble.com.  

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message