[
https://issues.apache.org/jira/browse/HBASE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686327#comment-13686327
]
Feng Honghua commented on HBASE-8721:
-------------------------------------
On the contrary, personally I think allowing client explicitly set timestamp
is giving client the ability to EXACTLY control the versions semantic, without
the impact from clock skew or HBASE-2256. By explicitly setting timestmaps for
each KVs he put, client know exactly at any time point which versions will
survive without worrying about exceptional cases such as clock skew or
HBASE-2256.
Below are 'acceptable' behaviors regarding delete/version from my point of
view.
1> version is determined by 'timestamp' only(same as current semantic),
HBase(we) determines which version survive (in Scan/Compact etc.) only by
timestamp.
2> delete can only mask puts happened before it('before' here is measured by
vector clock, mvcc in HBase, not by timestamp). All puts happened before a
delete are candidates to be masked by that delete, but whether a candidate put
will be actually masked by that delete further depends on whether the candidate
put's timestamp is smaller than or equal to delete's timestamp.
So delete's semantic is: to delete an existing exact version (deleteColumn)
or all existing smaller versions (deleteColumns / deleteFamily)
These two version/delete semantics/behaviors have no conflicts.
> Deletes can mask puts that happen after the delete
> --------------------------------------------------
>
> Key: HBASE-8721
> URL: https://issues.apache.org/jira/browse/HBASE-8721
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: Feng Honghua
> Attachments: HBASE-8721-0.94-V0.patch
>
>
> this fix aims for bug mentioned in http://hbase.apache.org/book.html 5.8.2.1:
> "Deletes mask puts, even puts that happened after the delete was entered.
> Remember that a delete writes a tombstone, which only disappears after then
> next major compaction has run. Suppose you do a delete of everything <= T.
> After this you do a new put with a timestamp <= T. This put, even if it
> happened after the delete, will be masked by the delete tombstone. Performing
> the put will not fail, but when you do a get you will notice the put did have
> no effect. It will start working again after the major compaction has run.
> These issues should not be a problem if you use always-increasing versions
> for new puts to a row. But they can occur even if you do not care about time:
> just do delete and put immediately after each other, and there is some chance
> they happen within the same millisecond."
--
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
