[
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:
rowLocksHeldByThread
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?
{code}
+ 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);
{code}
Could another thread come in and add to lockedRows before get to add this
rowKey to the thread local?
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
