[
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-v7.patch
Thanks, Stack, for the review. Judging by your comments I believe you're
addressing HBASE-8877-v6.patch (rather than HBASE-8877-0.94-v2.patch).
{quote}A bit of doc on this would help: ... rowLocksHeldByThread{quote}
Done.
{quote}hould 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){quote}
That's the only method that became a pass-through. I considered just removing
it - we're already changing the HRegion public methods from row locks - I
assumed that was OK to do in the singularity (not to mention the CP change).
It's only used by HBaseFsck and 3 tests. I've now inlined it directly. Let me
know if you think it needs to be deprecated for a release first.
{quote}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?{quote}
If we did get any locks then we apply those mutations for which we did get
locks, clean them up, return out to batchMutate which will continue again. If
we failed to get any locks at all, then it means the timeout expired (default
30 seconds) and by my reading it still goes through all the cleanup methods
then tries again. None of that logic was touched for these issues.
{quote}Is this racey?{quote}
Strictly rated G
{quote}Could another thread come in and add to lockedRows before get to add
this rowKey to the thread local?{quote}
Nope, lockedRows.putIfAbsent gives atomicity so the next thread would get back
a non null existingContext.
{quote}This should be finals{quote}
Agreed. Done.
Attached HBASE-8877-v7.patch
> 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
