Return-Path: 
 <dev-return-31563-apmail-hbase-dev-archive=hbase.apache.org@hbase.apache.org>
X-Original-To: apmail-hbase-dev-archive@www.apache.org
Delivered-To: apmail-hbase-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 58271D912
	for <apmail-hbase-dev-archive@www.apache.org>;
 Tue, 11 Dec 2012 22:37:28 +0000 (UTC)
Received: (qmail 76574 invoked by uid 500); 11 Dec 2012 22:37:25 -0000
Delivered-To: apmail-hbase-dev-archive@hbase.apache.org
Received: (qmail 76463 invoked by uid 500); 11 Dec 2012 22:37:25 -0000
Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@hbase.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@hbase.apache.org>
List-Post: <mailto:dev@hbase.apache.org>
List-Id: <dev.hbase.apache.org>
Reply-To: dev@hbase.apache.org
Delivered-To: mailing list dev@hbase.apache.org
Received: (qmail 76448 invoked by uid 99); 11 Dec 2012 22:37:25 -0000
Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Dec 2012 22:37:25 +0000
Received: from localhost (HELO mail-ob0-f169.google.com) (127.0.0.1)
  (smtp-auth username apurtell, mechanism plain)
  by minotaur.apache.org (qpsmtpd/0.29) with ESMTP;
 Tue, 11 Dec 2012 22:37:24 +0000
Received: by mail-ob0-f169.google.com with SMTP id v19so4606723obq.14
        for <multiple recipients>; Tue, 11 Dec 2012 14:37:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.64.70 with SMTP id m6mr10367619obs.15.1355265443909; Tue,
 11 Dec 2012 14:37:23 -0800 (PST)
Received: by 10.60.54.97 with HTTP; Tue, 11 Dec 2012 14:37:23 -0800 (PST)
In-Reply-To: 
 <CALte62wkRuZayQCyTvuw+mWpK=qCXzHttC6bZhL6JEBbOjGpKw@mail.gmail.com>
References: 
 <CAKfebOMVOE_GMVzrN8ACSuLstfZ811Y=p==X_Vt1uynGu8BnKw@mail.gmail.com>
	<CALte62wkRuZayQCyTvuw+mWpK=qCXzHttC6bZhL6JEBbOjGpKw@mail.gmail.com>
Date: Tue, 11 Dec 2012 14:37:23 -0800
Message-ID: 
 <CA+RK=_BNWHvci+sff79rKCMWsTvK3QsThPwhV5dBDOkY+j=v6A@mail.gmail.com>
Subject: Re: Proposal: Remove explicit RowLocks in 0.96
From: Andrew Purtell <apurtell@apache.org>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Cc: "user@hbase.apache.org" <user@hbase.apache.org>
Content-Type: multipart/alternative; boundary=14dae93a16995c520804d09b5338

--14dae93a16995c520804d09b5338
Content-Type: text/plain; charset=ISO-8859-1

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)

--14dae93a16995c520804d09b5338--