[HBASE-8877] Reentrant row locks

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 0.98.0, 0.95.2
• Component/s: Coprocessors, regionserver
• Hadoop Flags: Incompatible change, Reviewed
• Release Note: Changed the coprocessor RegionObserver methods preBatchMutate and postBatchMutate to remove the lock ids from the methods as lock ids are not longer used.
• Tags: 0.96notable
• Assignee: Dave Latham
• Reporter: Dave Latham
• Created: 05/Jul/13 15:28
• Updated: 15/Oct/13 04:46
• Resolved: 17/Jul/13 05:34

Description

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.

Issue Links

• relates to: HBASE-8806 Row locks are acquired repeatedly in HRegion.doMiniBatchMutation for duplicate rows.