[
https://issues.apache.org/jira/browse/HBASE-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051787#comment-16051787
]
Yu Li commented on HBASE-18144:
-------------------------------
bq. There is a parameter called waitForLock. In branch-1.1 if the batch put
thread already got some row to write(their locks are possessed), then when
getting the next lock, it will pass false to this parameter. So it won't wait
for another lock but process the gotten ones.
Ok, then it's clear why branch-1.1 don't have the problem (smile).
I think this dead-lock preventing logic should also be applied to our current
code base. I'm not sure but maybe this is a better solution than HBASE-17924?
> 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)
