[
https://issues.apache.org/jira/browse/HBASE-16525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-16525:
--------------------------
Priority: Critical (was: Major)
> [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: 2.0.0
>
>
> 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.
> [[email protected]] , [~eclark] FYI.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
