[
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13994785#comment-13994785
]
Jeffrey Zhong commented on HBASE-8763:
--------------------------------------
{quote}
Early- vs late-binding would change this patch?
{quote}
Yes, it makes the patch much easier for edits with durablity=SKIP_WAL &
ASYNC_WAL situation otherwise it would do similar things of HBASE-11135.
{quote}
I'm not sure I'm clear on what could be rolled back out of memstore around
flush. Or, can there be more doc on how mvcc and sequence id are interacting
here?
{quote}
During flush, we take a region write lock(prevent all writes coming into a
region), append a marker in MVCC queue, get flush sequence Id, take a mem store
snapshot and then release the region write lock. After lock release, we wait
for the MVCC marker we appended while holding the write lock in order for all
in-flight transactions before acquiring the region write lock to
complete(either succeed or rollback). Since there is only one copy of MVCC
which is a MutableLong object referenced by all related KVs, the rollback of
KVs from mem store should have no issue.
{quote}
Is the best write up on how this is going to work going forward what is above
in this issue?
{quote}
Sure. I'll modify this patch on top of HBASE-11135 and then a write up on the
final implementation.
> [BRAINSTORM] Combine MVCC and SeqId
> -----------------------------------
>
> Key: HBASE-8763
> URL: https://issues.apache.org/jira/browse/HBASE-8763
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: Enis Soztutar
> Assignee: Jeffrey Zhong
> Priority: Critical
> Attachments: hbase-8736-poc.patch, hbase-8763-poc-v1.patch,
> hbase-8763-v1.patch, hbase-8763_wip1.patch
>
>
> HBASE-8701 and a lot of recent issues include good discussions about mvcc +
> seqId semantics. It seems that having mvcc and the seqId complicates the
> comparator semantics a lot in regards to flush + WAL replay + compactions +
> delete markers and out of order puts.
> Thinking more about it I don't think we need a MVCC write number which is
> different than the seqId. We can keep the MVCC semantics, read point and
> smallest read points intact, but combine mvcc write number and seqId. This
> will allow cleaner semantics + implementation + smaller data files.
> We can do some brainstorming for 0.98. We still have to verify that this
> would be semantically correct, it should be so by my current understanding.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
