hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mahadev Konar <maha...@yahoo-inc.com>
Subject Re: question about locking in java singleton class
Date Thu, 14 Jan 2010 17:36:50 GMT
Hi Jaakko,
 The lock recipe has already been implemented in zookeeper under
src/recipes/lock (version 3.* I think). It has code to deal with
connectionloss as well. I would suggest that you use the recipe. You can
file jira's in case you see some shortcomings/bugs in the code.


Thanks
mahadev


On 1/14/10 1:32 AM, "Jaakko" <rosvopaallikko@gmail.com> wrote:

> Hi,
> 
> I'm trying to provide mutex services through a singleton class
> (methods lock and unlock). It basically follows lock recipe, but I'm
> having a problem how to handle connection loss properly if it happens
> during mutex wait:
> 
> pseudocode/snippet:
> 
> 
> public class SingletonMutex implements Watcher
> {
>     private Integer mutex;
>     private ZooKeeper zk;
> 
>     public void process(WatchedEvent event)
>     {
>         synchronized (mutex)
>         {
>             mutex.notifyAll();
>         }
>     }
> 
>     private String lock()
>     {
>         <create ephemeral znode>
>         <find children and do related checks>
> 
>         if (there_is_somebody_with_smaller_number)
>         {
>             mutex.wait();
> 
>             if (isConnected() == false)
>                 throw new Exception("foobar");
>         }
>     }
> }
> 
> Question is: If there is a server disconnect during mutex.wait, the
> thread will wake up without having any means to continue (or delete
> the znode), so it throws an exception. However, if this is only due to
> connection loss (and not session expire), the lock znode it has
> created previously will not be deleted, thus resulting in a deadlock.
> One way would be to use sessionId in lock name and check if we already
> have the lock when entering lock method. However, since this is
> singleton class and used by multiple threads, that approach won't
> work. Using thread ID for this purpose or some form of internal
> bookkeeping is also not very robust. Currently I just do zk.close and
> get another instance on connection loss, which seems to solve the
> problem.
> 
> Is there any other way to do this?
> 
> Thanks for any comments/suggestions,
> 
> -Jaakko


Mime
View raw message