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 Wed, 25 Jan 2017 06:49:26 GMT

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

ASF GitHub Bot commented on TEPHRA-210:

Github user gokulavasan commented on the issue:

    @poornachandra Addressed your comment by making getConfiguration method return a Configuration
which could be nullable. Please look at ``ensureValidTxLifetime`` method since we now will
have to throw an exception if Configuration is not available. Is that reasonable way to handle

> 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