You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Duo Zhang (Jira)" <ji...@apache.org> on 2021/05/31 16:00:00 UTC

[jira] [Commented] (HBASE-16525) [2.0] Cell timestamps can be assigned out of order with sequenceId

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

Duo Zhang commented on HBASE-16525:
-----------------------------------

I think the problem is still there. Assign timestamp and assign sequence id/mvcc are separated steps without lock protection.

> [2.0] Cell timestamps can be assigned out of order with sequenceId
> ------------------------------------------------------------------
>
>                 Key: HBASE-16525
>                 URL: https://issues.apache.org/jira/browse/HBASE-16525
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Priority: Critical
>             Fix For: 3.0.0-alpha-2
>
>
> While working on something else, noticed that in 2.0, we can end up with assigning timestamps out of order of sequenceId for the same row, thus ending with a case that a "later" mutation will not be visible due to an earlier mutation with a lower sequenceId. This can happen only in 2.0 code bases where we have the read-write lock based rowlocks. In 1.x, due to row locks being exclusive, we always order the cell timestamps in order of sequenceIds. 
> In HRegion.doMiniBatchMutate(), step 2 is to assign cell timestamps: 
> {code}
>       // STEP 2. Update any LATEST_TIMESTAMP timestamps
>       // We should record the timestamp only after we have acquired the rowLock,
>       // otherwise, newer puts/deletes are not guaranteed to have a newer timestamp
> {code}
> If two transactions that modify the same row starts concurrently, and t1 executes step 2 first, while t2 gets the sequenceId first, we can end up with two transactions where t1 has higher timestamp but lower seqId, and t2 lower timestamp but higher seqId. 
> Not sure how big a problem is this. One can say that the "order" of transactions is the order they execute step 2 (assign cell timestamps) rather than assign sequenceIds.  
> [~saint.ack@gmail.com] , [~eclark] FYI. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)