hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Proposal: Remove explicit RowLocks in 0.96
Date Tue, 11 Dec 2012 22:40:58 GMT
I would add another point to the reasoning:

5) Users can build application level rowlocks using HBase's CAS primitives,
or ZooKeeper / Curator recipes (since ZooKeeper is always available in
HBase environments), and these don't suffer the problems mentioned.


On Tue, Dec 11, 2012 at 2:37 PM, Andrew Purtell <apurtell@apache.org> wrote:

> I agree with all points. +1
>
>
> On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yuzhihong@gmail.com> wrote:
>
>> Including user mailing list.
>>
>> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
>> >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
>> >
>>
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message