+1 to what Camille is saying & suggestion to use generations On Wed, Jul 15, 2015 at 12:04 PM, Camille Fournier <[email protected]> wrote:
> If client a does a full gc immediately before sending a message that is > long enough to lose the lock, it will send the message out of order. You > cannot guarantee exclusive access without verification at the locked > resource. > > C > On Jul 15, 2015 3:02 PM, "Jordan Zimmerman" <[email protected]> > wrote: > > > 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 ([email protected]) > 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. > > >
