[ 
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
(v6.3.4#6332)

Reply via email to