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

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


+
Gregory Chanan 2012-12-11, 21:52
+
Ted Yu 2012-12-11, 22:00
+
Andrew Purtell 2012-12-11, 22:37
+
Andrew Purtell 2012-12-11, 22:40
Copy link to this message
-
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]
+
lars hofhansl 2012-12-11, 23:19
+
Stack 2012-12-12, 07:08
+
Gregory Chanan 2012-12-13, 00:31