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)