In my locking implementation, if a thread wants to wait for a lock, it will
create a watcher object, set a watch on the lock before it, and wait on the
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 are
waiting for a lock. To my understanding, only the default watcher receives
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?

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 will
create a watcher object, set a watch on the lock before it, and wait on the
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 are
waiting for a lock. To my understanding, only the default watcher receives
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?

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 will
> create a watcher object, set a watch on the lock before it, and wait on the
> 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 are
> waiting for a lock. To my understanding, only the default watcher receives
> 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?
>

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?

-JZ

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
> will
> > create a watcher object, set a watch on the lock before it, and wait on
> the
> > 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
> are
> > waiting for a lock. To my understanding, only the default watcher
> receives
> > 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?
> >
>

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

No, no guarantee.

Patrick

> 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 will
>> create a watcher object, set a watch on the lock before it, and wait on the
>> 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 are
>> waiting for a lock. To my understanding, only the default watcher receives
>> 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?
>>

I thought I might need one thread to perform an action before any other
thread continues to run, but I found a better way of going about it. Thanks.

On Wed, Jun 27, 2012 at 1:54 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> 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?
> >
>
> No, no guarantee.
>
> Patrick
>
> > 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
> will
> >> create a watcher object, set a watch on the lock before it, and wait on
> the
> >> 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
> are
> >> waiting for a lock. To my understanding, only the default watcher
> receives
> >> 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?
> >>
>

All watchers will get called with session expiration, disconnect, etc.

===================Jordan Zimmerman

On Jun 26, 2012, at 7:51 AM, "David Nickerson" <[EMAIL PROTECTED]> wrote:

> In my locking implementation, if a thread wants to wait for a lock, it will
> create a watcher object, set a watch on the lock before it, and wait on the
> 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 are
> waiting for a lock. To my understanding, only the default watcher receives
> 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?