[ 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....@gmail.com] , [~eclark] FYI. -- This message was sent by Atlassian Jira (v8.3.4#803005)