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. >
