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

Dave Latham commented on HBASE-8877:
------------------------------------

[~lhofhansl] Agreed that it's a bit fragile and that exactly was why I was 
initially concerned about checkAndMutate before I convinced myself it was safe 
and added the comment indicating that the nested release may have already 
released the locks.

Reference counts would change the contract (from current patch) and require 
clients like doMiniBatchMutation to track the number of times it acquires the 
lock on each row and then release them the same number of times as opposed to a 
simple releaseAll.  I can give it a shot to see how it turns out if you want to 
see 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

Reply via email to