[
https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053521#comment-16053521
]
Yu Li commented on HBASE-18233:
-------------------------------
bq. If a thread comes in via another path, will it mess up the expectation here?
Please correct me if I'm wrong boss:
Increment request in mid of a batch request would be "another thread", and I
think the logic could work well here. We're not expecting this getRowLock to be
the "only path" to get the row lock, but just one way. It's ok to conflict with
other threads, we will return what it should be: a read/write lock if no
contention or null if could not obtain the lock, only not that exclusive.
bq. In the else below, we ask NOT to wait for lock but doesn't the tryLock call
block until it gets the lock; i.e. we are blocking until we get the read lock.
Oh maybe some misunderstanding here. From javadoc of {{Lock.tryLock()}}:
{code}
Acquires the lock only if it is free at the time of invocation.
Acquires the lock if it is available and returns immediately with the value
true. If the lock is not available then this method will return immediately
with the value false.
{code}
We won't wait given no timeout.
> We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
> -------------------------------------------------------------------------
>
> Key: HBASE-18233
> URL: https://issues.apache.org/jira/browse/HBASE-18233
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.2.7
> Reporter: Allan Yang
> Assignee: Allan Yang
> Attachments: HBASE-18233-branch-1.2.patch
>
>
> Please refer to the discuss in HBASE-18144
> https://issues.apache.org/jira/browse/HBASE-18144?focusedCommentId=16051701&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16051701
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
