[jira] [Commented] (HBASE-8877) Reentrant row locks

["Dave Latham (JIRA)" <ji...@apache.org>]

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

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

A few changes in this patch compared to the latest similar patch on HBASE-8806:
 - fixed the heap size logic to match the new fields
 - wrapped a couple lines that were longer than 100 chars
 - changed releaseMyRowLocks method to free the list of locks from the thread local so that each thread doesn't wind up having very long empty lists hanging around
 - changed the row lock methods from public to package private as they are only used inside HRegion (and by some tests)
 - added some comments to checkAndMutate to make clear row it's reusing locks
 - renamed new thread local field to rowLocksHeldByThread
                
> 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.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