[
https://issues.apache.org/jira/browse/HBASE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13700971#comment-13700971
]
Ted Yu commented on HBASE-8877:
-------------------------------
{code}
- public OperationStatus[] batchMutate(
- Pair<Mutation, Integer>[] mutationsAndLocks) throws IOException {
- return batchMutate(mutationsAndLocks, false);
+ public OperationStatus[] batchMutate(Mutation[] mutations) throws
IOException {
{code}
Should dev@hbase be polled for the removal of lock Id ?
{code}
/**
- * Returns existing row lock if found, otherwise
- * obtains a new row lock and returns it.
- * @param lockid requested by the user, or null if the user didn't already
hold lock
- * @param row the row to lock
- * @param waitForLock if true, will block until the lock is available,
otherwise will
- * simply return null if it could not acquire the lock.
- * @return lockid or null if waitForLock is false and the lock was
unavailable.
+ * public void getRowLock(byte [] row) throws IOException {
+ * internalObtainRowLock(row, true);
*/
{code}
The change in javadoc seems unnecessary.
{code}
+ static class RowLockContext {
{code}
RowLockContext can be private, right ?
> 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
