[
https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054309#comment-16054309
]
stack commented on HBASE-18233:
-------------------------------
bq. 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.
Ok. Sounds good. Is it possible to add a test for threads coming via a route
that is concurrent and NOT the batch route to prove all works as expected?
bq. Oh maybe some misunderstanding here.
Yes. Thank you for fixing my misunderstanding.
What about this question: "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?"
Is the benefit that we no longer block? That we make-do with however many
locks we were able to attain?
Any benefit seen in testing?
This work is starting to look real nice. Thanks lads.
> 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)
