You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Clint Morgan (JIRA)" <ji...@apache.org> on 2010/03/04 21:09:27 UTC
[jira] Created: (HBASE-2286) [Transactional Contrib] Correctly
handle or avoid cases where writes occur in same millisecond
[Transactional Contrib] Correctly handle or avoid cases where writes occur in same millisecond
----------------------------------------------------------------------------------------------
Key: HBASE-2286
URL: https://issues.apache.org/jira/browse/HBASE-2286
Project: Hadoop HBase
Issue Type: Improvement
Components: contrib
Reporter: Clint Morgan
Attachments: hbase-2286.patch
This patch fixes a few issues where puts/deletes occur with the same timestamp.
In the indexing layer, we avoid a Delete followed by a Put to the same row for the index update. When the row is the same, we can just do the put.
In the transactional layer, we correctly handled put, put, scan. This way the scan will see the last put, even if they have the same timestamp.
Remove the sleep to fix the putPutScan transactional test, and run it many times to be sure we hit the case where they are in the same millisecond.
Also some small cleanup, null handling, and fail-fast changes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HBASE-2286) [Transactional Contrib] Correctly
handle or avoid cases where writes occur in same millisecond
Posted by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Daniel Cryans resolved HBASE-2286.
---------------------------------------
Resolution: Fixed
Fix Version/s: (was: 0.20.4)
0.20.5
Assignee: Clint Morgan
Hadoop Flags: [Reviewed]
Committed to branch and trunk. Thanks for the good work guys.
> [Transactional Contrib] Correctly handle or avoid cases where writes occur in same millisecond
> ----------------------------------------------------------------------------------------------
>
> Key: HBASE-2286
> URL: https://issues.apache.org/jira/browse/HBASE-2286
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: contrib
> Reporter: Clint Morgan
> Assignee: Clint Morgan
> Fix For: 0.20.5, 0.21.0
>
> Attachments: hbase-2286-v2-trunk.patch, hbase-2286-v2.patch, hbase-2286.patch
>
>
> This patch fixes a few issues where puts/deletes occur with the same timestamp.
> In the indexing layer, we avoid a Delete followed by a Put to the same row for the index update. When the row is the same, we can just do the put.
> In the transactional layer, we correctly handled put, put, scan. This way the scan will see the last put, even if they have the same timestamp.
> Remove the sleep to fix the putPutScan transactional test, and run it many times to be sure we hit the case where they are in the same millisecond.
> Also some small cleanup, null handling, and fail-fast changes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-2286) [Transactional Contrib] Correctly
handle or avoid cases where writes occur in same millisecond
Posted by "Clint Morgan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Clint Morgan updated HBASE-2286:
--------------------------------
Fix Version/s: 0.20.3
0.21.0
Please review
> [Transactional Contrib] Correctly handle or avoid cases where writes occur in same millisecond
> ----------------------------------------------------------------------------------------------
>
> Key: HBASE-2286
> URL: https://issues.apache.org/jira/browse/HBASE-2286
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: contrib
> Reporter: Clint Morgan
> Fix For: 0.20.3, 0.21.0
>
> Attachments: hbase-2286.patch
>
>
> This patch fixes a few issues where puts/deletes occur with the same timestamp.
> In the indexing layer, we avoid a Delete followed by a Put to the same row for the index update. When the row is the same, we can just do the put.
> In the transactional layer, we correctly handled put, put, scan. This way the scan will see the last put, even if they have the same timestamp.
> Remove the sleep to fix the putPutScan transactional test, and run it many times to be sure we hit the case where they are in the same millisecond.
> Also some small cleanup, null handling, and fail-fast changes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-2286) [Transactional Contrib] Correctly
handle or avoid cases where writes occur in same millisecond
Posted by "Clint Morgan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Clint Morgan updated HBASE-2286:
--------------------------------
Attachment: hbase-2286.patch
> [Transactional Contrib] Correctly handle or avoid cases where writes occur in same millisecond
> ----------------------------------------------------------------------------------------------
>
> Key: HBASE-2286
> URL: https://issues.apache.org/jira/browse/HBASE-2286
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: contrib
> Reporter: Clint Morgan
> Attachments: hbase-2286.patch
>
>
> This patch fixes a few issues where puts/deletes occur with the same timestamp.
> In the indexing layer, we avoid a Delete followed by a Put to the same row for the index update. When the row is the same, we can just do the put.
> In the transactional layer, we correctly handled put, put, scan. This way the scan will see the last put, even if they have the same timestamp.
> Remove the sleep to fix the putPutScan transactional test, and run it many times to be sure we hit the case where they are in the same millisecond.
> Also some small cleanup, null handling, and fail-fast changes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.