phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas D'Silva (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-3907) Use LATEST_TIMESTAMP when UPDATE_CACHE_FREQUENCY is not zero
Date Fri, 02 Jun 2017 21:09:04 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035426#comment-16035426
] 

Thomas D'Silva commented on PHOENIX-3907:
-----------------------------------------

[~jamestaylor]

You are referring to setting the MetaDataMutationResult mutation time to QueryConstants.UNSET_TIMESTAMP
when update cache frequency is set and the cached entity hasn't expired right ? Later on when
we create mutations if the timestamp is set to UNSET_TIMESTAMP we use the LATEST_TIMESTAMP.

{code}
 // Do not make rpc to getTable if
        // 1. table is a system table
        // 2. table was already resolved as of that timestamp
        if (table != null && !alwaysHitServer
                && (systemTable || resolvedTimestamp == tableResolvedTimestamp ||
connection.getMetaDataCache().getAge(tableRef) < table.getUpdateCacheFrequency())) {
            return new MetaDataMutationResult(MutationCode.TABLE_ALREADY_EXISTS, QueryConstants.UNSET_TIMESTAMP,
table);
        }
{code}

If the cached entry expired the MetaDataMutationResult mutation time is set to the server
timestamp (same as the behavior of tables without  UPDATE_CACHE_FREQUENCY set). I think it
makes sense to be consistent and always set the MetaDataMutationResult mutation time to QueryConstants.UNSET_TIMESTAMP
if UPDATE_CACHE_FREQUENCY is set (except for the UPSERT SELECT/ DELETE corner case when the
alwaysHitServer flag is set to true).



> Use LATEST_TIMESTAMP when UPDATE_CACHE_FREQUENCY is not zero
> ------------------------------------------------------------
>
>                 Key: PHOENIX-3907
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3907
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>
> For non transactional tables, currently with UPDATE_CACHE_FREQUENCY, we'll use LATEST_TIMESTAMP
*most* of the time, until the cached entity expires, in which case we'll use the server timestamp.
This seems a bit strange and inconsistent. Instead (for non transactional tables), we should
always use LATEST_TIMESTAMP if UPDATE_CACHE_FREQUENCY is non zero, with the exception of the
corner case for UPSERT SELECT and DELETE where the same table is being read and written to
(see changes to FromCompiler for PHOENIX-3823).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message