[ https://issues.apache.org/jira/browse/HBASE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707481#comment-13707481 ]
Dave Latham commented on HBASE-8877: ------------------------------------ {quote}What was the unit for min/max/mean values ?{quote} Each trial measures the number of milliseconds to execute a batchMutate of 25000 puts. > 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-8807-v4-microbenchmark.txt, HBASE-8877.patch, > HBASE-8877-v2.patch, HBASE-8877-v3.patch, HBASE-8877-v4.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