[
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985127#comment-13985127
]
stack commented on HBASE-8763:
------------------------------
You the man [~jeffreyz]
Spelling here waitForPreviousTransactoinsComplete
What is happening here?
syncOrDefer(txid, durability);
+ // Get LogSequenceNumber from WAL Sync
+ if(walEdit.getLogKey() != null) {
+ seqNumber.setValue(walEdit.getLogKey().getLogSeqNum());
+ }
The seqNumber of the last wallEdit added to the WAL and sync'd? The seq number
could be well beyond this in actually? Does that matter? Should we let you
have access to last sync'd id out of WAL?
You import but don't use?
+import org.apache.commons.lang.mutable.MutableInt;
+import org.apache.commons.lang.mutable.MutableLong;
... maybe a few times.
Why you use the MutableLong instead of say a long or a volatile?
Will do a closer review later. So far looks great.
> [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_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)
