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]
