[ https://issues.apache.org/jira/browse/HBASE-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295241#comment-13295241 ]
stack commented on HBASE-6195: ------------------------------ Xing Nice work. When you run MultiThreadsIncrement w/ your patch in place, do the numbers come out better? It looks like this increment was originally added by: {code} ------------------------------------------------------------------------ r1027681 | jgray | 2010-10-26 11:50:13 -0700 (Tue, 26 Oct 2010) | 1 line HBASE-2946 Increment multiple columns in a row at once {code} There is some discussion there that there may be danger around flush time. Might be useful to review. See https://issues.apache.org/jira/browse/HBASE-2946?focusedCommentId=12924737&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12924737 In original patch, it has our updating MemStore before we append to WAL. I seem to recall that there was a reason why we had this unorthodoxy but I am unable to find it now. Thanks for fixing this Xing. We should backport? > 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