[
https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053511#comment-16053511
]
stack commented on HBASE-18233:
-------------------------------
When the lock was exclusive, a thread had the lock or it did not. When
reentrant read/write lock, many threads could have the read lock. Doesn't the
patch presume that the only way to get the row lock is via this path? There are
other routes to the row lock other than this one. If a thread comes in via
another path, will it mess up the expectation here?
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.
In other words, why have the tryLock with no timeout?
5180 if(waitForLock) {
5181 lockAvailable =
result.getLock().tryLock(this.rowLockWaitDuration, TimeUnit.MILLISECONDS);
5182 } else {
5183 lockAvailable = result.getLock().tryLock();
5184 }
Where is the benefit? The benefit is that if some one comes through looking for
a write lock, first we'll flush any read lock batches? Any benefit seen?
nits: could use the simpler BOOLEAN? DO THIS: DO THAT; construct in a few
places in the patch.
> 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)
