Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <1355267951.15555.YahooMailNeo@web140604.mail.bf1.yahoo.com>
References: 
 <CAKfebOMVOE_GMVzrN8ACSuLstfZ811Y=p==X_Vt1uynGu8BnKw@mail.gmail.com>
	<CALte62wkRuZayQCyTvuw+mWpK=qCXzHttC6bZhL6JEBbOjGpKw@mail.gmail.com>
	<CA+RK=_BNWHvci+sff79rKCMWsTvK3QsThPwhV5dBDOkY+j=v6A@mail.gmail.com>
	<CA+RK=_CGC1REJqNohvHG1vmfOvfJVWmEuxgwmDQmpAdQDB68yw@mail.gmail.com>
	<CAAha9a1py3G_qB6A9xBPOiDj7ZnF8mcHU7YfZuPaWVQz_7O_OA@mail.gmail.com>
	<1355267951.15555.YahooMailNeo@web140604.mail.bf1.yahoo.com>
Date: Tue, 11 Dec 2012 19:35:06 -0500
Message-ID: 
 <CAPQV63Wxd5Pfv5WdzVGQzkGTmRNBj6G_ptBoSpE7HOK3ohr+cA@mail.gmail.com>
Subject: Re: Proposal: Remove explicit RowLocks in 0.96
From: Jean-Marc Spaggiari <jean-marc@spaggiari.org>
To: dev@hbase.apache.org, user <user@hbase.apache.org>
Content-Type: text/plain; charset=UTF-8

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 <lhofhansl@yahoo.com>:
> 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 <jon@cloudera.com>
> To: dev@hbase.apache.org
> Cc: Andrew Purtell <apurtell@apache.org>; "user@hbase.apache.org"
> <user@hbase.apache.org>
> 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 <apurtell@apache.org> 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 <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)
>>
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com