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