hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12975) SplitTranaction, RegionMergeTransaction to should have InterfaceAudience of LimitedPrivate(Coproc,Phoenix)
Date Thu, 05 Feb 2015 18:51:37 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307757#comment-14307757

Lars Hofhansl commented on HBASE-12975:

Hmm... I see. So you actually would want to implement a "joined split", where either both
region succeed or both fail, atomically.

Can you think of an interface for that, which we could pull out, along with an implementation
that does that?
I.e. a SplitTransaction that takes multiple region and splitkeys and only succeed when all
are done. That might actually be tricky.

Or maybe an interface that has execute, commit, and rollback? Then you can execute on both,
and commit when both executes are successful. That may be easier. Need to think carefully
what commit/rollback mean and what happens when a region server dies before it commits.

> SplitTranaction, RegionMergeTransaction to should have InterfaceAudience of LimitedPrivate(Coproc,Phoenix)
> ----------------------------------------------------------------------------------------------------------
>                 Key: HBASE-12975
>                 URL: https://issues.apache.org/jira/browse/HBASE-12975
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Rajeshbabu Chintaguntla
>            Assignee: Rajeshbabu Chintaguntla
>            Priority: Minor
>             Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.11
>         Attachments: HBASE-12975.patch
> Making SplitTransaction, RegionMergeTransaction limited private is required to support
local indexing feature in Phoenix to ensure regions colocation. 
> We can ensure region split, regions merge in the coprocessors in few method calls without
touching internals like creating zk's, file layout changes or assignments.
> 1) stepsBeforePONR, stepsAfterPONR we can ensure split.
> 2) meta entries can pass through coprocessors to atomically update with the normal split/merge.
> 3) rollback on failure.

This message was sent by Atlassian JIRA

View raw message