hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8763) [BRAINSTORM] Combine MVCC and SeqId
Date Wed, 30 Apr 2014 03:45:21 GMT

    [ 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)

Mime
View raw message