+1 Lets do what Jon Hsieh suggests deprecating on next 0.94 release and removing in 0.96.
St.Ack 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 >
