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

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


Copy link to this message
-
Re: Proposal: Remove explicit RowLocks in 0.96
I'm not an HBase expert, but if the lock is not fully working, I don't
see the point to keep it on 0.96.x and agree with deprecating it on
0.94.4.

Also, I think Andrew's option is a very good fit. We already have
Zookeeper available, and HBase might be able to come with something
like a row lock based on Zookeeper reservation. Maybe on a later
version?

JM

2012/12/11, lars hofhansl <[EMAIL PROTECTED]>:
> There two different questions here, right:
> 1. Remove rowlocks as a client side API (HBASE-7315)
> 2. Remove rowlocks from server code and replace it with better mechanism
> (HBASE-7263)
>
> +1 on both. And also +1 on deprecating them in 0.94.4.
>
> -- Lars
>
>
>
> ________________________________
>  From: Jonathan Hsieh <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Andrew Purtell <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]>
> Sent: Tuesday, December 11, 2012 2:50 PM
> Subject: Re: Proposal: Remove explicit RowLocks in 0.96
>
> +1.  Deprecate in the next 0.94.x release and remove from 0.96/trunk?
>
> Jon.
>
> On Tue, Dec 11, 2012 at 2:40 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
>
>> 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 <[EMAIL PROTECTED]>
>> wrote:
>>
>> > I agree with all points. +1
>> >
>> >
>> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> >
>> >> Including user mailing list.
>> >>
>> >> 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
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > 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)
>>
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // [EMAIL PROTECTED]