hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Latham (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-8877) Reentrant row locks
Date Mon, 15 Jul 2013 23:28:50 GMT

     [ https://issues.apache.org/jira/browse/HBASE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dave Latham updated HBASE-8877:

    Attachment: HBASE-8877-refCounts-v2.patch

Thanks, Ted, for taking a look.  Sorry for changing the same file while you were looking.

{quote}Should an assertion (or exception) be placed in the if block above ?{quote}
The same behavior is there in the previous patch (v7) (and nearly the same in trunk as well)
so it's not really a change.  That said, this state cannot happen as I read the code, but
if it did then the row locks may be stuck, so an exception sounds good to me so that it would
be louder.

{quote}Can RowLock class be package private ?{quote}
It should be the same scope as the getRowLock method (needed for clients to keep references
and release them) which I believe we decided to be public (for CPs for example).

I've attached HBASE-8877-refCounts-v2.patch with the change to throw an exception on inconsistent
row lock state.
> Reentrant row locks
> -------------------
>                 Key: HBASE-8877
>                 URL: https://issues.apache.org/jira/browse/HBASE-8877
>             Project: HBase
>          Issue Type: Bug
>          Components: Coprocessors, regionserver
>            Reporter: Dave Latham
>            Assignee: Dave Latham
>             Fix For: 0.95.2
>         Attachments: hbase-8877-0.94-microbenchmark.txt, HBASE-8877-0.94.patch, HBASE-8877-0.94-v2.patch,
HBASE-8877.patch, hbase-8877-refCounts-microbenchmarks.txt, HBASE-8877-refCounts.patch, HBASE-8877-refCounts-v2.patch,
HBASE-8877-v2.patch, HBASE-8877-v3.patch, hbase-8877-v4-microbenchmark.txt, HBASE-8877-v4.patch,
HBASE-8877-v5.patch, HBASE-8877-v6.patch, HBASE-8877-v7.patch
> HBASE-8806 revealed performance problems with batch mutations failing to reacquire the
same row locks.  It looks like HBASE-8806 will use a less intrusive change for 0.94 to have
batch mutations track their own row locks and not attempt to reacquire them.  Another approach
will be to support reentrant row locks directly.  This allows simplifying a great deal of
calling code to no longer track and pass around lock ids.
> One affect this change will have is changing the RegionObserver coprocessor's methods
preBatchMutate and postBatchMutate from taking a {{MiniBatchOperationInProgress<Pair<Mutation,
Integer>> miniBatchOp}} to taking a {{MiniBatchOperationInProgress<Mutation> miniBatchOp}}.
 I don't believe CPs should be relying on these lock ids, but that's a potential incompatibility.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message