hbase-issues mailing list archives

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

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

stack commented on HBASE-8877:

Very nice patch.  Nice cleanup.

A bit of doc on this would help:


It is a nice trick.  It is worth talking up!

Should we deprecate stuff like this,    public OperationStatus[] put(Put[] puts) throws IOException
{, the methods that you have made into pass-throughs? (Fine in another issue)

When we fall out here because we failed to acquire a lock, what happens?  We apply all mutations
for which we did get a lock?  And then return the client reporting as failed those we did
not get a lock on?

           assert !shouldBlock : "Should never fail to get lock when blocking";
           break; // stop acquiring more rows for this batch

Is this racey?

+        RowLockContext existingContext = lockedRows.putIfAbsent(rowKey, rowLockContext);
+        if (existingContext == null) {
+          // Row is not already locked by any thread, add it to this thread's list
+          rowLocksHeldByThread.get().add(rowKey);

Could another thread come in and add to lockedRows before get to add this rowKey to the thread

This should be finals

+    private CountDownLatch latch;
+    private Thread thread;

Otherwise +1 on commit.
> 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-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