Mailing-List: contact hbase-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-user@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of germoglio@gmail.com
 designates 74.125.46.31 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=xMR8ZLVkb1xRsZJQu1NBy9fHoTdEDkjEm2GkhXlHPjkOTx4Gqg/A7jFhCLfWLUFtw4
         w1ZkoWw0LqMaEu8VhdRCxzyOX/sC+lZkzSTXHnx34y0v1Z2scc1HHHKXHCTdQulzicyh
         ZUN5hltVyzVVvZnnXzMwVrA6/pK7h6R57vLr0=
MIME-Version: 1.0
In-Reply-To: <7c962aed0905141140k3fc0f7adse624c518c0f37dd2@mail.gmail.com>
References: <29bed2720905081629r6d50a895g87304b05f5a0a4fa@mail.gmail.com>
	<7c962aed0905081914m47827c3dn9c31a9fb719e2cbb@mail.gmail.com>
	<29bed2720905101019v311b10b2tf8ae66a504c5221@mail.gmail.com>
	<7c962aed0905122210y5300aa94y8c381ae1aa22773e@mail.gmail.com>
	<7c962aed0905130826x18efa2cbmffcb525f1e57b023@mail.gmail.com>
	<29bed2720905131944j84685d1s99101b4929016422@mail.gmail.com>
	<92eebe280905132300y52b3f04cq3f65911eda5acbbb@mail.gmail.com>
	<7c962aed0905140716m2f47cb86n662d664b5a3a5aa@mail.gmail.com>
	<29bed2720905140944r41f89bbcwffa591af87d6db86@mail.gmail.com>
	<7c962aed0905141140k3fc0f7adse624c518c0f37dd2@mail.gmail.com>
From: Guilherme Germoglio <germoglio@gmail.com>
Date: Thu, 14 May 2009 21:31:18 -0300
Message-ID: <29bed2720905141731q56f1df49v84e5fc5082fe8f5d@mail.gmail.com>
Subject: Re: Problems when executing many (?) HTable.lockRow()
To: hbase-user@hadoop.apache.org
Content-Type: multipart/alternative; boundary=001e680f11445042a50469e89197

--001e680f11445042a50469e89197
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, May 14, 2009 at 3:40 PM, stack <stack@duboce.net> wrote:

> No consideration has been made for changes in how locks are done in new
> 0.20.0 API.  Want to propose something Guilherme?  Could new zk-arbitrated
> locking be done inside the confines of the RowLock object?


I think so.

If nothing is to be changed on RowLock class, we could use the following
approach:

Considering the line as is today:

*RowLock lock = htable.lockRow(row);*

*htable.lockRow(row)*, instead of contacting the regionserver and requesting
a lock for the given row, it would contact zk for a lock, just as the lock
recipe<http://hadoop.apache.org/zookeeper/docs/current/recipes.html#sc_recipes_Locks>[1].
Notice that it will be waiting for the lock just as it does today, the
only difference is that regionserver resources (e.g., RPC thread) aren't
used. After it receives the lock, htable would: (1) randomly generate a
lockid, (2) put an entry in a Map<lockid, zk node pathname>, (3) create a
RowLock using the lockid and (4) return the method.

>From this point, any operation could be performed even without passing
rowlock as parameter, zookeeper + the implementation of the lock recipe in
htable are now ensuring that no other client would be performing any
operation concurrently on the given row. [2]

Finally, *htable.unlockRow(lock)* must be invoked, which would make Htable
delete the matching zk node (remember the Map<lockid, zk node pathname>).

One good thing of this approach is that we don't have to worry about lock
leases: if the client dies, zk will notice at some point in the future and
release the lock. And if the client forgets to unlock the row, its code is
wrong. (:

However, if we are to redesign the API, I would propose write and read
locks. Then htable would have two methods: HTable.lockRowForRead(row),
HTable.lockRowForWrite(row) [3] and the lock recipe to be implemented would
be the Shared Locks
recipe<http://hadoop.apache.org/zookeeper/docs/current/recipes.html#Shared+Locks>.


[1] We may design carefully how the locknode would be created according to
zk constraints on how many nodes it can manage in a single directory. Maybe
we should do something like:
/hbase/locks/table-name/hash-function(row)/row/{read-, write-}

[2] I agree that we are not protecting ourselves from a malicious client
using HTable, who could simply "forget" to request the lock for the given
row and then mess everything. But this is how it's everywhere, isn't it?

[3] Suggest better method names, please!


> St.Ack
>
>
> On Thu, May 14, 2009 at 9:44 AM, Guilherme Germoglio <germoglio@gmail.com
> >wrote:
>
> > This way, HTable could directly request for read or write row locks (
> >
> http://hadoop.apache.org/zookeeper/docs/current/recipes.html#Shared+Locks)
> > using zookeeper wrapper. The problem is that the client api would change
> a
> > little. Would these changes fit into the client api redesign for 0.20
> > (HBASE-1249)?
> >
> > On Thu, May 14, 2009 at 11:16 AM, stack <stack@duboce.net> wrote:
> >
> > > On Wed, May 13, 2009 at 11:00 PM, Joey Echeverria <joey42@gmail.com>
> > > wrote:
> > >
> > > > Wouldn't it be better to implement the row locks using zookeeper?
> > > >
> > >
> > > THBase was done before ZK was in the mix.  Now its here, we should look
> > > into
> > > using it.
> > >
> > > St.Ack
> > >
> >
> >
> >
> > --
> > Guilherme
> >
> > msn: guigermoglio@hotmail.com
> > homepage: http://germoglio.googlepages.com
> >
>


-- 
Guilherme

msn: guigermoglio@hotmail.com
homepage: http://germoglio.googlepages.com

--001e680f11445042a50469e89197--