[
https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981132#action_12981132
]
stack commented on HBASE-2856:
------------------------------
Thinking on the way home and after chatting more with Ryan, I'm thinking that
we do not want two sets of sequence numbers -- one at regionserver level (HLog
sequence id) and then another HRegion-scoped one. All edits are bottlenecked
via the WAL -- give or take the skip WAL write flag and deferred flush -- and
so arbitrarily breaking the transaction into two phases, the WAL write then the
commit to memstore, seems like it gains us little; edits will stack up behind
the WAL chicane anyways.
Paranoia regards performance issues come from long waits in 'wait to be
visible' phase when the Transaction spanned WAL.
I'm thinking now that for this issue, we do it first 'correct' -- e.g. use HLog
sequence number throughout and start the 'transaction' pre-WAL -- and then in a
new issue figure the smarts that will get us over the slowness we've seen
before taking this tack.
> 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, 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.
-
You can reply to this email to add a comment to the issue online.
