-Re: Dealing with an expired session
Jordan Zimmerman 2012-06-26, 20:30
Even if it did (I don't actually know), I'd be nervous about having that
kind of dependency in my app. What's the reason you need this?
On Tue, Jun 26, 2012 at 1:25 PM, David Nickerson <
[EMAIL PROTECTED]> wrote:
> Is there any guarantee of order? For example, does the default watcher
> receive the notification first?
> On Tue, Jun 26, 2012 at 11:35 AM, Rakesh R <[EMAIL PROTECTED]> wrote:
> > When the ZK disconnects/synconnects/expires all the watchers will get the
> > notifications. I think, you should have the KeeperState checks in the
> > respctive watchers and can do the thread handling logics.
> > ________________________________________
> > From: David Nickerson [[EMAIL PROTECTED]]
> > Sent: Tuesday, June 26, 2012 8:20 PM
> > To: ZooKeeper mailing list
> > Subject: Dealing with an expired session
> > In my locking implementation, if a thread wants to wait for a lock, it
> > create a watcher object, set a watch on the lock before it, and wait on
> > watcher. When the watch gets triggered, the watcher notifies any threads
> > that are waiting on it.
> > If the session expires, I would like to wake up all of the threads that
> > waiting for a lock. To my understanding, only the default watcher
> > a notification that the session has expired. If this is the case, then I
> > need to maintain a list somewhere of all of the watchers that threads are
> > waiting on so that I can notify them all.
> > Does this sound correct?