[
https://issues.apache.org/jira/browse/HBASE-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052743#comment-16052743
]
stack commented on HBASE-18144:
-------------------------------
Other thoughts are that the doMiniBatch where it takes all locks up front
before going on to apply Mutations is not appropriate after the move to
read/write row locks; it made sense in branch-1.1. where the row lock was
costly and reentrant. Once you had the lock, you could do a bunch of mutations
under its umbrella. When read/write lock, the lock does the refcounting
internally. If all read lock requests, then all threads make progress. Its the
write lock requests that are blockers. Better to have the batch fail quickly
with a bunch of read-lock successes than have it wait (deadlock) for 30 seconds
at a time just because the batch had a write lock in the mix that it was unable
to attain in time; better to fail fast and then retry on a new rpc? Someone
probably figured the heuristic long ago. We need to do a bit of study.
On the sort, it costs. Was wondering if we could exploit the sort otherwise
perhaps later in the processing of mutations (is this the only sort in the
write pipeline?)
> Forward-port the old exclusive row lock; there are scenarios where it
> performs better
> -------------------------------------------------------------------------------------
>
> Key: HBASE-18144
> URL: https://issues.apache.org/jira/browse/HBASE-18144
> Project: HBase
> Issue Type: Bug
> Components: Increment
> Affects Versions: 1.2.5
> Reporter: stack
> Assignee: stack
> Fix For: 2.0.0, 1.3.2, 1.2.7
>
> Attachments: DisorderedBatchAndIncrementUT.patch,
> HBASE-18144.master.001.patch
>
>
> Description to follow.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
