[
https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484600#comment-13484600
]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
I think the special memstoreTS logic in Increment/Append is a separate issue
than what I'm bringing up here. I could be wrong (I've just really started
looking into this code). Could you explain what is wrong about the following:
The current value of some cell is 10.
I issue two concurrent requests:
A) a check and put where check value = 10, put value = 11
B) a put where put value = 50
The only result at the end of these operations that seems reasonable to me is
the value of the cell being 50. If A occurred first (ACID wise), then our
values go 10->11->50. If B occurred first, then our values go 10->50 (and the
checkAndPut fails). Or do we just not consider checkAndPuts to be transactions?
My reading of the code is that we could get 11. B goes first but releases the
rowLock before completing his MVCC memstore insert. Then A goes, reads 10 and
puts 50.
> Read/Updates (increment,checkAndPut) should properly read MVCC
> --------------------------------------------------------------
>
> Key: HBASE-7051
> URL: https://issues.apache.org/jira/browse/HBASE-7051
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.96.0
> Reporter: Gregory Chanan
>
> See, for example:
> {code}
> // TODO: Use MVCC to make this set of increments atomic to reads
> {code}
> Here's an example of what I can happen (would probably be good to write up a
> test case for each read/update):
> Concurrent update via increment and put.
> The put grabs the row lock first and updates the memstore, but releases the
> row lock before the MVCC is advanced. Then, the increment grabs the row lock
> and reads right away, reading the old value and incrementing based on that.
> There are a few options here:
> 1) Waiting for the MVCC to advance for read/updates: the downside is that you
> have to wait for updates on other rows.
> 2) Have an MVCC per-row (table configuration): this avoids the unnecessary
> contention of 1)
> 3) Transform the read/updates to write-only with rollup on read.. E.g. an
> increment would just have the number of values to increment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
