Andrew Purtell created HBASE-6696:
-------------------------------------

             Summary: 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

Reply via email to