Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Proposal: Remove explicit RowLocks in 0.96

Copy link to this message
Re: Proposal: Remove explicit RowLocks in 0.96

Lets do what Jon Hsieh suggests deprecating on next 0.94 release and
removing in 0.96.

On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]>wrote:

> Over in HBASE-7263 there has been some discussion about removing support
> for explicit RowLocks in 0.96.  This would involve the following:
> - Remove lockRow/unlockRow functions in HTable and similar
> - Remove constructors for Put/Delete/Increment/Get that take RowLocks
> - functions in HRegion no longer take lockIds (checkAndPut, append,
> increment, etc).  This would affect coprocessors that call directly into
> those functions.
> I have a patch in HBASE-7315 with the details.
> This would violate our usual rule of deprecating a feature one release
> before removing.  The reasoning is as follows:
> 1) RowLocks are broken
>  They are only kept in the memory associated with the region, so on a
> split, region move, RS crash, they just disappear
> 2) 0.96 is special
> Now seems like a good time to clean things up since we've made some
> incompatible changes already (e.g. protobufing) and we could have a cleaner
> client implementation
> 3) RowLocks have been deprecated "in spirit" for awhile
> Here's a post from 2009 cautioning against their use:
> http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
> and a more recent example:
> http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
> 4) RowLocks are hard to use effectively
> Clients can deadlock or starve themselves, either by forgetting to release
> the RowLocks or by starving other non-contending row operations by
> occupying server handlers stuck waiting to acquire the locks.
> Thoughts?
> Greg