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]
