Enis Soztutar created HBASE-16525:
-------------------------------------
Summary: [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
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.3.4#6332)
