[
https://issues.apache.org/jira/browse/HBASE-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-6696:
----------------------------------
Assignee: (was: Andrew Purtell)
> Add CP hooks pre and post split transaction point-of-no-return
> --------------------------------------------------------------
>
> Key: HBASE-6696
> URL: https://issues.apache.org/jira/browse/HBASE-6696
> Project: HBase
> Issue Type: Improvement
> Components: Coprocessors, regionserver
> Affects Versions: 0.94.2, 0.95.2
> Reporter: Andrew Purtell
>
> In the discussion "Improving Coprocessor postSplit/postOpen synchronization"
> on user@hbase, a user implementing a secondary indexing scheme writes in:
> {quote}
> The goal with splits is to create two new daughter regions with the
> corresponding splits of the secondary indexes and lock these regions such
> that Puts/Deletes that occur while postSplit is in progress will be queued
> up so we don't run into consistency issues. [...] As of right now, the HBase
> coprocessors do not easily support a way to achieve this level of consistency
> in that there is no way to distinguish a region being opened from a split or
> a regular open.
> {quote}
> Setting aside the particulars of the use case, the issue is the {{preSplit}}
> hook does not provide the identities of the daughter regions (they don't
> exist yet) and the {{postSplit}} hook, while providing the identities of the
> daughter regions, runs after the master has processed the split and the
> daughters are already opened or opening. A CP implementer has no interception
> point available where the daughters exist but are not yet open.
> This JIRA proposes to add two new CP hooks to just before and after the
> point-of-no-return (PONR) in the split transaction: {{preSplitPONR}} and
> {{postSplitPONR}}. Perhaps the naming can be improved. This will address the
> above use case but additionally support overloading of the split transaction
> itself. We also need to address observer notification if the split
> transaction fails. This is like HBASE-5827 but scoped to this specific
> consideration only.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
