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

Amitanand Aiyer commented on HBASE-5241:
----------------------------------------

@Lars: Was discussing the replication issue a little more with Kannan. It does 
seem like there may be corner cases in which the exact order does matter. Even 
if we leave things the way they are; and clients do not take control of the 
timestamp.

Say for example we have two Puts from the client side. -- If both hit the 
server in quick succession, they could both be issued the same milli-second 
timestamp. Which one of them wins, will then be entirely determined by the 
order in which they are applied. If we apply them in different order, we could 
end up with different values.

It seems to me that to ensure determinism in terms of what the clients see; it 
would be crutial to have an internal timestamp that orders every operation 
(using something like Lamport's logical clock, instead real clock).

I do agree with you that it would be nice if timestamp were considered an 
internal detail that clients don't take control of. But, we would still have to 
include memstoreTS or Log Seq Id to ensure deterministic replay.
                
> Deletes should not mask Puts that come after it.
> ------------------------------------------------
>
>                 Key: HBASE-5241
>                 URL: https://issues.apache.org/jira/browse/HBASE-5241
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Amitanand Aiyer
>         Attachments: HBASE-5241.D1731.1.patch
>
>
> Suppose that we have a delete row, and then followed by the put. The delete 
> row
> can mask the put, unless there was a major compaction in between.
> Now that we are flushing the memstoreTS to disk, along with the KVs, we 
> should be able
> to differentiate whether or not the Put happened after the Delete and offer 
> better 
> delete semantics.
> Couldn't find a pre-existing JIRA that already discusses this, so creating 
> one.
> Seems related to https://issues.apache.org/jira/browse/HBASE-2406, but is not 
> quite the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to