hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8877) Reentrant row locks
Date Mon, 15 Jul 2013 18:46:49 GMT

    [ https://issues.apache.org/jira/browse/HBASE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708803#comment-13708803
] 

Lars Hofhansl commented on HBASE-8877:
--------------------------------------

Do we need to do reference counting on the locks?

Technically the patch is correct, since an HBase lock does not outlive an RPC request, but
it still seems a tad fragile.
For example what if in the future a method does its own locking: It acquires a lock on a row,
does some logic, releases the lock. If a method higher up in the call stack had the row locked,
it is now unlocked from under it.

                
> 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-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

Mime
View raw message