hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Daniel Cryans (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2256) Delete row, followed quickly to put of the same row will sometimes fail.
Date Wed, 24 Feb 2010 18:17:28 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837923#action_12837923

Jean-Daniel Cryans commented on HBASE-2256:

bq. Yes, I'm sure that the millisecond nature of timestamps comes in to play here. However,
I'm not setting any timestamps, and was under the impression that hbase would always reflect
the state of the last operation done. Is this not a valid assumption?

Do you see this delete problem even on a fully distributed setup? In my experience, they only
happen in unit tests where all components are in the same JVM whereas when network is involved
some milliseconds will separate two consecutive operations. 

bq. A related question. If I do two puts (w/latest timestamp), am I guaranteed to see the
last one? I'm sure many users operate under this assumption.

If they have the same timestamp, there's no guarantee.

bq. So, for a given row, I'm doing a delete of an entire row, then a put of two cells in different
families. Then I do a get.

See my first comment, it's ok when not done in unit tests. Like the bigtable paper says, if
you need a finer granularity than millisecond you may need to redefine the timestamps (using
something like microseconds).

> Delete row, followed quickly to put of the same row will sometimes fail.
> ------------------------------------------------------------------------
>                 Key: HBASE-2256
>                 URL: https://issues.apache.org/jira/browse/HBASE-2256
>             Project: Hadoop HBase
>          Issue Type: Bug
>    Affects Versions: 0.20.3
>            Reporter: Clint Morgan
>         Attachments: hbase-2256.patch
> Doing a Delete of a whole row, followed immediately by a put to that row will sometimes
miss a cell. Attached is a test to provoke the issue.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message