[ https://issues.apache.org/jira/browse/HBASE-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhihong Ted Yu reopened HBASE-6195: ----------------------------------- In 0.94 build 259, the new test failed: {code} Failed tests: testParallelIncrementWithMemStoreFlush(org.apache.hadoop.hbase.regionserver.TestHRegion): expected:<2000> but was:<1999> {code} > Increment data will be lost when the memstore is flushed > -------------------------------------------------------- > > Key: HBASE-6195 > URL: https://issues.apache.org/jira/browse/HBASE-6195 > Project: HBase > Issue Type: Bug > Components: regionserver > Reporter: Xing Shi > Assignee: ShiXing > Fix For: 0.96.0, 0.94.1 > > Attachments: 6195-trunk-V7.patch, 6195.addendum, > HBASE-6195-trunk-V2.patch, HBASE-6195-trunk-V3.patch, > HBASE-6195-trunk-V4.patch, HBASE-6195-trunk-V5.patch, > HBASE-6195-trunk-V6.patch, HBASE-6195-trunk.patch > > > There are two problems in increment() now: > First: > I see that the timestamp(the variable now) in HRegion's Increment() is > generated before got the rowLock, so when there are multi-thread increment > the same row, although it generate earlier, it may got the lock later. > Because increment just store one version, so till now, the result will still > be right. > When the region is flushing, these increment will read the kv from snapshot > and memstore with whose timestamp is larger, and write it back to memstore. > If the snapshot's timestamp larger than the memstore, the increment will got > the old data and then do the increment, it's wrong. > Secondly: > Also there is a risk in increment. Because it writes the memstore first and > then HLog, so if it writes HLog failed, the client will also read the > incremented value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira