[
https://issues.apache.org/jira/browse/HBASE-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052697#comment-16052697
]
stack commented on HBASE-18144:
-------------------------------
[~anoop.hbase] The old code is pretty hard to fathom. The waitForLock operation
in particular was cryptic. When set, if the current thread is NOT the thread
that owns the lock, then return the null lock. The null lock signals the end of
a batch. The batch needs to be processed before we can give this new thread the
row lock. The old exclusive lock was reentrant; if the same thread passing us
Mutations, then we'd only get the lock the first time through. All subsequent
mutations would operate under the umbrella of the exclusive lock (until a new
thread came in... then we'd 'flush').
[~allan163] The temporary deadlocking you describe seems legit (thanks!). I
think sorting helps but does not eliminate. Let me play around some here. I
think I can get your suggestion deployed on the problematic cluster... Let me
see.
> 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)
