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

Jonathan Gray commented on HBASE-4527:
--------------------------------------

Yeah, seems like we could utilize the memstoreTS once we solve those issues and 
then we don't care about the timestamp being the same.  But we'd then have to 
expose RWCC to the API because checkAndPut would need to specify it?  ugh
                
> Fix versioning such that every update is unique
> -----------------------------------------------
>
>                 Key: HBASE-4527
>                 URL: https://issues.apache.org/jira/browse/HBASE-4527
>             Project: HBase
>          Issue Type: Wish
>            Reporter: stack
>
> I wanted to use checkAndPut but there is a case where the check will not fail 
> though the cell has been updated: if a cell is update with exactly the value 
> it had before, we'll not know its been changed.  hbase-4507 did a checkAndPut 
> where you could pass a timestamp as part of the check so we'd check the cell 
> value AND that the timestamp was the same.
> This would work in most regards but one; an update is done in the same 
> millisecond.  This is generally impossible but in a distributed system where 
> clocks drift and a region can be moved to a server whose clock is retarded, 
> it is within the realm of possibilities that it could happen.  So we should 
> deal.
> One thought is that the version is made for sure unique.  We could make the 
> timestamp wider still so probability of the edits arriving within the same 
> microsecond -- or whatever it is that a double gives you -- would require us 
> to run through a couple of billion universe expand/contract cycles or we 
> could have a monotonically increasing sequence id per millisecond.
> There could be some overlap between this issue and the persisting of rwcc to 
> the filesystem (though not currently as rwcc is implemented).

--
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