[
https://issues.apache.org/jira/browse/HBASE-6696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459801#comment-13459801
]
Andrew Purtell commented on HBASE-6696:
---------------------------------------
[~stack] Thoughts on when the cut point for 0.96 might be?
> 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.96.0, 0.94.2
> Reporter: Andrew Purtell
> Assignee: 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
