You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Gregory Chanan (JIRA)" <ji...@apache.org> on 2012/10/25 05:28:11 UTC
[jira] [Created] (HBASE-7051) Read/Updates (increment,checkAndPut)
should properly read MVCC
Gregory Chanan created HBASE-7051:
-------------------------------------
Summary: 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "ramkrishna.s.vasudevan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484803#comment-13484803 ]
ramkrishna.s.vasudevan commented on HBASE-7051:
-----------------------------------------------
Yes.. what Gregory says is possible.. i tried to reproduce this scenario that he mentioned. It happens..
So if thread B is just before waiting for MVCC to complete and by the time of thread A does the check operation it is going to succeed.
Now the MVCC completes and the put as part of checkAndPut gets completed thus overwriting what the thread B has written.
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485704#comment-13485704 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
BTW, the approach I took in HBASE-4583 is akin to #1.
> 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
> Fix For: 0.94.3, 0.96.0
>
>
> 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
[jira] [Updated] (HBASE-7051) CheckAndPut should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl updated HBASE-7051:
---------------------------------
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Committed to 0.94 and 0.96.
Thanks for bringing up the issue and Gregory and the review.
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488163#comment-13488163 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Yep... Fails without this patch, but passes with it.
This should go into 0.94 and 0.96.
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "ramkrishna.s.vasudevan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484806#comment-13484806 ]
ramkrishna.s.vasudevan commented on HBASE-7051:
-----------------------------------------------
Also this applies to other versions also right? Not only trunk?
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485551#comment-13485551 ]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
@Ram:
regarding option 3: for an increment imagine you can just insert something into the memstore that says "increment by x". Since you don't have to read, you can just do what all the other writes do (i.e. don't wait for MVCC, just hold the row lock up to the sync point). Reads become more complicated, of course.
Option 2:
I was just thinking you would need to spend some memory per-row to hold the MVCC. Probably okay (similar to the row lock already?), but would need some investigation.
@Lars:
If you were to assign this to yourself, what approach would you take? Holding the row lock until the WAL is synced during writes? Waiting for all transactions to complete in read/updates?
I'm down for trying out the #2 idea. We could benchmark it against the other approaches. Perhaps I should file a new JIRA for that?
> 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
> Fix For: 0.94.3, 0.96.0
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488143#comment-13488143 ]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
Patch looks good. Mind testing with Ram's test patch over in HBASE-7071? (I.e. that it fails w/o your patch, passes with).
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13487581#comment-13487581 ]
Hadoop QA commented on HBASE-7051:
----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12551489/7051.txt
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include any new or modified tests.
Please justify why no new tests are needed for this patch.
Also please list what manual steps were performed to verify this patch.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop 2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 85 warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 3 new Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit
Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//testReport/
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//console
This message is automatically generated.
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485530#comment-13485530 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Just posted a patch to HBASE-4583. We can do something similar here.
Gregory, were you going to work on this? Otherwise I'll assign it to me.
> 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
> Fix For: 0.94.3, 0.96.0
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484212#comment-13484212 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Actually checkAndPut is correct, no? I see no special logic that mucks with the memstoreTS or similar.
The only really special operations are Increment and Append.
@Ram: Since Increment and Append are not idempotent we cannot simply retry them (see discussion on HBASE-6390).
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13487545#comment-13487545 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
I would say this (checkAndXXX) is somewhat more critical than HBASE-4583 as it can actually lead to incorrect, *permanent* results.
> 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
> Fix For: 0.94.3, 0.96.0
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484602#comment-13484602 ]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
Sorry last sentence should be:
"Then A goes, reads 10 and puts 11"
> 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
[jira] [Updated] (HBASE-7051) Read/Updates (increment,checkAndPut)
should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl updated HBASE-7051:
---------------------------------
Fix Version/s: 0.96.0
0.94.3
> 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
> Fix For: 0.94.3, 0.96.0
>
>
> 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
[jira] [Commented] (HBASE-7051) CheckAndPut should properly read
MVCC
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488513#comment-13488513 ]
Hudson commented on HBASE-7051:
-------------------------------
Integrated in HBase-0.94 #562 (See [https://builds.apache.org/job/HBase-0.94/562/])
HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404379)
Result = FAILURE
larsh :
Files :
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484618#comment-13484618 ]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
What does "Yes" refer to?
I'm suggesting that the result of the above two operations should always be 50. Having the checkAndPut begin and complete a memstore insert before doing the read (option 1 above), is one example of how to get those semantics.
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484610#comment-13484610 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Yes. There is nothing special about checkAndPut.
Maybe I am confused... What specifically do you want to fix w.r.t. checkAndPut?
(I think the only weird things we have that do not honor MVCC are Increment and Append)
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485055#comment-13485055 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
I see. In HRegion.doMiniBatchPut we release the rowlock(s) before we roll the readPoint (completeMemstoreInsert). So for checkAndPut is not enough to hold the rowlock, since an earlier Put could have released the lock but not yet rolled readPoint... Is that what you guys are saying?
I agree that is a problem and a side-effect of releasing the rowlock early to avoid holding it, while the WAL is sync'ed.
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "ramkrishna.s.vasudevan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483936#comment-13483936 ]
ramkrishna.s.vasudevan commented on HBASE-7051:
-----------------------------------------------
append() and incrment() also does not honour retries also. HBASE-6390 was raised for that but we did not proceed on that ?
> 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
[jira] [Commented] (HBASE-7051) CheckAndPut should properly read
MVCC
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488579#comment-13488579 ]
Hudson commented on HBASE-7051:
-------------------------------
Integrated in HBase-TRUNK #3503 (See [https://builds.apache.org/job/HBase-TRUNK/3503/])
HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404377)
Result = FAILURE
larsh :
Files :
* /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485104#comment-13485104 ]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
Yes, that's what I'm saying Lars.
What do you think about the options I give in the description? You mentioned holding the rowlock longer, which would also work, but (presumably) slow down all operations, not just checkAndPuts/increments/appends.
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483921#comment-13483921 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Note that this is as simple as it looks. Increments are not idempotent. The skirt the issue by making changes visible immediately so that other increments see the result all previous increments.
If that were not the case two increments of 1 with a base value of 0 could still just lead to 1, even when they are both applied atomically.
That is why the memstoreTS is set to 0 for increments (making it visible immediately).
> 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
[jira] [Updated] (HBASE-7051) Read/Updates (increment,checkAndPut)
should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl updated HBASE-7051:
---------------------------------
Status: Patch Available (was: Open)
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488176#comment-13488176 ]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
I'm +1 on this. I haven't looked at HBASE-7071 enough to +1 it. Want me to?
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485128#comment-13485128 ]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
Lars: that's option 1. The downside is you have to wait for writes to complete on other rows, which is unnecessary. I don't think there is a race in there, but could be wrong.
Option #2 is use an MVCC per row. Is that just infeasible? We could make it an option like "faster read/updates"
Option #3 is make the read/updates write-only. That's probably more difficult.
> 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
[jira] [Comment Edited] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483921#comment-13483921 ]
Lars Hofhansl edited comment on HBASE-7051 at 10/25/12 6:15 AM:
----------------------------------------------------------------
Note that this is not as simple as it looks. Increments are not idempotent. The skirt the issue by making changes visible immediately so that other increments see the result all previous increments.
If that were not the case two increments of 1 with a base value of 0 could still just lead to 1, even when they are both applied atomically.
That is why the memstoreTS is set to 0 for increments (making it visible immediately).
Edit: Forgot an important "not" :)
was (Author: lhofhansl):
Note that this is as simple as it looks. Increments are not idempotent. The skirt the issue by making changes visible immediately so that other increments see the result all previous increments.
If that were not the case two increments of 1 with a base value of 0 could still just lead to 1, even when they are both applied atomically.
That is why the memstoreTS is set to 0 for increments (making it visible immediately).
> 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
[jira] [Updated] (HBASE-7051) CheckAndPut should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl updated HBASE-7051:
---------------------------------
Summary: CheckAndPut should properly read MVCC (was: Read/Updates (increment,checkAndPut) should properly read MVCC)
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Ted Yu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483859#comment-13483859 ]
Ted Yu commented on HBASE-7051:
-------------------------------
bq. be good to write up a test case for each read/update
+1
Looks like option #3 is better.
> 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
[jira] [Assigned] (HBASE-7051) Read/Updates (increment,checkAndPut)
should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl reassigned HBASE-7051:
------------------------------------
Assignee: Lars Hofhansl
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
>
> 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
[jira] [Comment Edited] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483921#comment-13483921 ]
Lars Hofhansl edited comment on HBASE-7051 at 10/25/12 6:16 AM:
----------------------------------------------------------------
Note that this is not as simple as it looks. Increments are not idempotent. They skirt the issue by making changes visible immediately so that other increments see the result of all previous increments.
If that was not the case two increments of 1 with a base value of 0 could still just lead to 1, even when they are both applied atomically.
That is why the memstoreTS is set to 0 for increments (making it visible immediately).
Edit: Forgot an important "not" and spelling :)
was (Author: lhofhansl):
Note that this is not as simple as it looks. Increments are not idempotent. The skirt the issue by making changes visible immediately so that other increments see the result all previous increments.
If that were not the case two increments of 1 with a base value of 0 could still just lead to 1, even when they are both applied atomically.
That is why the memstoreTS is set to 0 for increments (making it visible immediately).
Edit: Forgot an important "not" :)
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485565#comment-13485565 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
I'd probably go with #1 honestly (as I said above it's not as nuclear as I had thought). I do not think #2 or #3 are worth the effort/risk.
We always wait for all other transactions - in this region - to finish (that is true even for normal puts), this is a nice and simple design in HBase. Changing that to MVCC/row would also break the multi row transaction stuff I added (but that is only exposed through a coprocessor endpoint so breaking that would potentially be OK).
MVCC is already per region, I do not think we should add a finer granularity here.
> 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
> Fix For: 0.94.3, 0.96.0
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484678#comment-13484678 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
I don't see how that can happen. checkAndMutate takes a row lock, reads the row (following MVCC), and updates the row (which will also follow the MVCC protocol).
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "ramkrishna.s.vasudevan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485358#comment-13485358 ]
ramkrishna.s.vasudevan commented on HBASE-7051:
-----------------------------------------------
@Gregory
Option #3 can you pls explain more.
Option #2-> what is the infeasibility you see? I have not thought on the soln for this anyway. If it is feasible i prefer #2.
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484632#comment-13484632 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
"Yes" was agreeing that 50 should always be the outcome. Is that ever not the case?
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484634#comment-13484634 ]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
Great. My surface-level reading of the code was that it could be 11, but I'll work on an actual test case :).
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485497#comment-13485497 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Thinking about this a bit more. Maybe the "nuclear" option isn't that nuclear after all.
The internalPut or internalDelete of checkAndMutate will wait for all prior transactions to finish anyway. Now we just wait in the beginning, so we get only slightly less concurrency but correctness.
I think the same will actually work for Increment and Append and we can get rid of the setting-the-memstoreTS-to-0 nonsense.
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488268#comment-13488268 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Sigh... I also meant HBASE-7077. So this one + HBASE-7077. :)
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485316#comment-13485316 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Can you explain #3 more.
In the end this was really broken by the work to release the lock before the WAL is sync'ed (and since for that be correct MVCC need to be rolled forward after the WAL sync'ed, which means after the lock was released).
> 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
[jira] [Commented] (HBASE-7051) CheckAndPut should properly read
MVCC
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490359#comment-13490359 ]
Hudson commented on HBASE-7051:
-------------------------------
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404379)
Result = FAILURE
larsh :
Files :
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485498#comment-13485498 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Hit "Add" too early. Of course if the check condition is false, we get worse performance because now we waited for all previous transaction where in old code we wouldn't have.
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485504#comment-13485504 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Also revived HBASE-4583.
> 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
> Fix For: 0.94.3, 0.96.0
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488174#comment-13488174 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
OK... Lemme commit this, followed by HBASE-7071. Any objections?
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488160#comment-13488160 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
You mean HBASE-7077 I assume :)
Yeah, will have a look.
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Gregory Chanan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483933#comment-13483933 ]
Gregory Chanan commented on HBASE-7051:
---------------------------------------
Hmm...interesting :).
The example in the description doesn't use two increments, though. Admittedly a weird case. But the same example should work with increment replaced with checkAndPut, which isn't as strange.
> 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
[jira] [Updated] (HBASE-7051) Read/Updates (increment,checkAndPut)
should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl updated HBASE-7051:
---------------------------------
Attachment: 7051.txt
Super simple patch. Just wait for prior MVCC transactions to finish, before we execute the Get.
> 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
> Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> 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
[jira] [Commented] (HBASE-7051) Read/Updates
(increment,checkAndPut) should properly read MVCC
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485126#comment-13485126 ]
Lars Hofhansl commented on HBASE-7051:
--------------------------------------
Holding the rowlock longer would require us to hold the lock while we sync the WAL (because MVCC visibility must come after we sync the lock).
The nuclear option would be to wait for all MVCC transactions to finish:
{code}
MultiVersionConsistencyControl.WriteEntry w = mvcc.beginMemstoreInsert();
mvcc.advanceMemstore(w);
mvcc.waitForRead(w);
{code}
This will wait for all prior transactions to finish. Even then there might be a race still.
> 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