hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Ming (Ming)" <ming....@esgyn.cn>
Subject RE: help, try to use HBase's checkAndPut() to implement distribution lock
Date Tue, 09 Aug 2016 16:58:47 GMT
Thanks Ted for the questions.

1. what if the process of owner of the lock dies?
I didn't think of this... This is really an issue. I don't have a good answer. One possibility
is to have a lease of each lock, owner must renew it periodically until release it. The getLock
can check the last timestamp to see if it is expired. But I have no idea how the lock owner
can periodic renew the lock lease, spawn a new thread to do that? So, this makes me trying
to abandon this idea.

2. How can other processes obtain the lock?
The getLock() has input param of table, so any process can give the tablename and invoke getLock(),
it check the row 0 value in an atomic check and put operation. So if the 'table lock' is free,
anyone should be able to get it I think.

Maybe I have to study the Zookeeper's distributed lock recipes? 

Thanks,
Ming

-----Original Message-----
From: Ted Yu [mailto:yuzhihong@gmail.com] 
Sent: Wednesday, August 10, 2016 12:26 AM
To: user@hbase.apache.org
Subject: Re: help, try to use HBase's checkAndPut() to implement distribution lock

What if the process of owner of the lock dies ?
How can other processes obtain the lock ?

Cheers

On Tue, Aug 9, 2016 at 8:19 AM, Liu, Ming (Ming) <ming.liu@esgyn.cn> wrote:

> Hi, all,
>
> I want to implement a simple 'table lock' in HBase. My current idea is 
> for each table, I choose a special rowkey which NEVER be used in real 
> data, and then use this row as a 'table level lock'.
>
> The getLock() will be:
>
>   getLock(table, cf, cl)
>   {
>      rowkey = 0 ; //which never used in real data
>
>     //generate a UUID, thread ID + an atomic increamental sequence 
> number for example. Call it myid
>      genMyid(myid);
>
>      while(TRUE)
>      {
>          ret = table.checkAndPut ( rowkey, cf , cl , '0' , myid);
>          if (ret == true ) get the lock
>              return myid;
>          else
>              sleep and continue; //retry, maybe can retry for timeout 
> here, or wait forever here
>       }
>    }
>
> The releaseLock() may be:
>
>    releaseLock(table, cf, cl, myid)
>    {
>        Rowkey = 0;
>         ret = checkAndPut ( rowkey , cf , cl , myid , '0' );  //If I 
> am holding the lock
>         if (ret == TRUE) return TRUE;
>         else  return FALSE;
>  }
>
> So one caller get lock, and others must wait until the caller release 
> it, and only the lock holder can release the lock. So if one 
> getLock(), it can then modify the table, others during this period must wait.
>
> I am very new in lock implementation, so I fear there are basic 
> problems in this 'design'.
> So please help me to review if there are any big issues about this idea?
> Any help will be very appreciated.
>
> Thanks a lot,
> Ming
>
Mime
View raw message