[ 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