hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12975) SplitTranaction, RegionMergeTransaction to should have InterfaceAudience of LimitedPrivate(Coproc,Phoenix)
Date Fri, 27 Feb 2015 02:16:05 GMT

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

Andrew Purtell commented on HBASE-12975:
----------------------------------------

Near the current tail of HBASE-12972, [~rajeshbabu] and I had this exchange:

[~rajeshbabu]:
{quote}
The new interfaces for SplitTransaction, RegionMergeTransaction in the patch may not fully
helpful for reimplementing the local indexes split/merge without diving into the details.
I think we can handle the SplitTransaction,RegionMergeTransaction changes in separate JIRA(may
be HBASE-12975 here).

To support local index regions split/merge I think splittransaction should be changed so that
it should also split more than one region atomically and the steps should be changed like
this.
1) We should be able pass/add one or more regions to SplitTransaction.
2) run steps before PONR(or commit) for all the regions.
3) commit split mutations of all the regions
4) run steps after PONR(or commit) for all the regions
5) Any failures before PONR rollback the regions completed steps before PONR.

This way in case of one region it should work as usual how it works currently.
Apart from this before actual split execution starts we should give provision to add more
regions to split through coprocessors. So this way we need not touch any internals.

Similar way we can change for regions merge as well.
{quote}

[~apurtell]:
{quote}
We can definitely split out the SplitTransaction and RegionMergeTransaction changes, my only
concern there is then the Region interface changes aren't sufficient to remove HRegion reference/use
in Phoenix.

I don't think we should allow users of the transactions to reach inside and direct what happens
when. On the other hand we could provide APIs for registering callbacks for when different
phases happen, and can take that a step further and allow callbacks to trigger an abort by
throwing an exception.

As for specifying what region(s) to run a transaction on, can you use the new factories? Create
a factory, call its create() method with the desired regions(s) to get a transaction instance),
and then run it?
{quote}

We could develop this further here? Hopefully we can all get on the same page that the only
way SplitTransaction and RegionMergeTransaction should have an interface audience of LimitedPrivate
is if they become _interfaces_ that don't leak internal details, are not types that can be
directly extended. 

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

Mime
View raw message