[
https://issues.apache.org/jira/browse/HBASE-12975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307541#comment-14307541
]
Andrew Purtell commented on HBASE-12975:
----------------------------------------
-1
SplitTransaction involves too many low level details. This is what
SplitTransaction does internally (in 0.98):
- Maintains the rollback journal
- Directly accesses and edits META table entries
- Directly accesses and modifies splitting state znodes and assignment state
- Responsible for calling coprocessor hooks
- Directly opens regions in worker threads
- Directly splits files in worker threads
- Responsible for cleaning up failed splits
The preponderance of these things cannot be said to be stable in any
LimitedPrivate interface sense. We would have to stop making changes in all of
those areas lest we break assumptions in code that overrides this stuff. Get
the details wrong and regions are permanently unavailable until operator
intervention and maybe surgery with custom tools. Some parts of HBase have to
remain private. This is the same rationale as was applied to HBASE-12566 and is
consistent with that decision.
> 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)
