[
https://issues.apache.org/jira/browse/HBASE-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052732#comment-16052732
]
stack commented on HBASE-18144:
-------------------------------
[~allan163] Yeah, even with sorting, allowing that threads can be preempted
(unscheduled) while trying to attain locks, there is nothing to prevent your
scenario. It does seem harder to manufacture if locks are being taken in order
requiring more parties participating to achieve deadlock.
Let me try HBASE-17924 at the problematic site and see if it improves things.
On your #2, above, with read/write locks, we have to take the lock every time
so the lock keep account of reads vs writes outstanding; we can't do the logic
that was in branch-1.1.
> 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)
