[
https://issues.apache.org/jira/browse/HBASE-11945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14129583#comment-14129583
]
Todd Lipcon commented on HBASE-11945:
-------------------------------------
bq. Consider we are writing to same rowkey from a lot of map tasks running
across multiple nodes.
bq. Will the behavior be the serial writes?
The behavior has always been somewhat serial writes if you're writing to the
same row key. There are some optimizations here around early lock release so
the throughput is good, but they're definitely serialized if they're in the
same row.
This issue is about a case where you might have two writes from the same client
in the same batch getting re-ordered when they get committed.
bq. Would the above code prevent lock acquisition ?
hmm.. good catch, yea, maybe the 'break' actually prevents this issue. Does
anyone have time to write the functional test I suggested above?
> 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)
