[
https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989365#comment-12989365
]
stack commented on HBASE-2856:
------------------------------
Chatting w/ Benoît last night, he had a good suggestion. He suggested we NOT
add extra long to the KV, that instead we just use the already existing
in-memory only memstorets that is in each KV. He suggested that on open of a
storefile, that we just pick up its oldest sequence number or assign a sequence
number on opening and keep that too in memory associated with the storefile.
Chatting, whenever we read in a KV from a store file, we could insert into the
memstorets field the storefiles sequence number; all edits in a storefile would
have the same sequence number. When we flush, and we bring online the new
storefile, it would have the flush sequence number. We would still need to
move to using sequence number instead of the incrementing number we have in
RWCC and we'd need to have the transaction, for correctness, span the WAL where
it doesn't now, but this suggestion would save our upping the Key part of KV
when persisted.
Trying the above on Ryan.
> TestAcidGuarantee broken on trunk
> ----------------------------------
>
> Key: HBASE-2856
> URL: https://issues.apache.org/jira/browse/HBASE-2856
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.89.20100621
> Reporter: ryan rawson
> Assignee: stack
> Priority: Blocker
> Fix For: 0.92.0
>
> Attachments: 2856-v2.txt, 2856-v3.txt, 2856-v4.txt, 2856-v5.txt,
> acid.txt
>
>
> TestAcidGuarantee has a test whereby it attempts to read a number of columns
> from a row, and every so often the first column of N is different, when it
> should be the same. This is a bug deep inside the scanner whereby the first
> peek() of a row is done at time T then the rest of the read is done at T+1
> after a flush, thus the memstoreTS data is lost, and previously 'uncommitted'
> data becomes committed and flushed to disk.
> One possible solution is to introduce the memstoreTS (or similarly equivalent
> value) to the HFile thus allowing us to preserve read consistency past
> flushes. Another solution involves fixing the scanners so that peek() is not
> destructive (and thus might return different things at different times alas).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
