tephra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TEPHRA-210) Streamline where tephra properties are fetched in TransactionProcessor coprocessor
Date Thu, 26 Jan 2017 02:15:27 GMT

    [ https://issues.apache.org/jira/browse/TEPHRA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839049#comment-15839049

ASF GitHub Bot commented on TEPHRA-210:

Github user poornachandra commented on the issue:


> Streamline where tephra properties are fetched in TransactionProcessor coprocessor
> ----------------------------------------------------------------------------------
>                 Key: TEPHRA-210
>                 URL: https://issues.apache.org/jira/browse/TEPHRA-210
>             Project: Tephra
>          Issue Type: Improvement
>            Reporter: Gokul Gunasekaran
>            Assignee: Gokul Gunasekaran
>             Fix For: 0.11.0-incubating
> Tephra properties that are being in the TransactionProcessor coprocessor are:
> TxConstants.READ_NON_TX_DATA
> TxConstants.Manager.CFG_TX_MAX_LIFETIME
> TxConstants.TransactionPruning.PRUNE_ENABLE
> TxConstants.TransactionPruning.PRUNE_STATE_TABLE
> Out of the above properties, first two are table specific and thus ideally should come
from the tableDesc (and can default to the value in env.getConfiguration). The other three
properties should fetched from a ``Configuration`` provided by a protected method that could
be overriden by derived classes (default implementation could still fetch it from env.getConfiguration).
Moreover, these two properties are used in filtering of data during Hbase client calls and
thus need to be available right away (unlike the other three properties which are used only
in background operations such as compaction).
> Use Case:  When Tephra is used in other projects, the user of TransactionProcessor coprocessor
can provide a way to get this configuration instead of relying on hbase-site.xml always.
> Proposal: Read the table specific properties in coprocessor, such as ALLOW_EMPTY_VALUES,
READ_NON_TX_DATA from tableDescriptor and fall back to env.getConfiguration. For other three
properties, introduce a method whose default implementation returns env.getConfiguration()
that contains those properties, which could be overriden by derived classes. Also, these three
values should loaded lazily when required during compaction/flush.

This message was sent by Atlassian JIRA

View raw message