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

["Enis Soztutar (JIRA)" <ji...@apache.org>]

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.  

[~saint.ack@gmail.com] , [~eclark] FYI. 




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)