[
https://issues.apache.org/jira/browse/HBASE-11945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129565#comment-14129565
]
Ted Yu commented on HBASE-11945:
--------------------------------
bq. C1: manages to acquire the lock for a later row2 op
In HRegion#doMiniBatchMutation() around line 2570:
{code}
if (rowLock == null) {
// We failed to grab another lock
assert !shouldBlock : "Should never fail to get lock when blocking";
break; // stop acquiring more rows for this batch
{code}
Would the above code prevent lock acquisition ?
> Client writes may be reordered under contention
> -----------------------------------------------
>
> Key: HBASE-11945
> URL: https://issues.apache.org/jira/browse/HBASE-11945
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.98.6
> Reporter: Todd Lipcon
>
> I haven't seen this bug in practice, but I was thinking about this a bit and
> think there may be a correctness issue with the way that we handle client
> batches which contain multiple operations which touch the same row. The
> client expects that these operations will be performed in the same order they
> were submitted, but under contention I believe they can get arbitrarily
> reordered, leading to incorrect results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
