[
https://issues.apache.org/jira/browse/PHOENIX-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14581006#comment-14581006
]
James Taylor commented on PHOENIX-1812:
---------------------------------------
I think there may be a problem with null being a wildcard for equals in general
(probably not for the single table case, though), but [~maryannxue] can
confirm. Maryann - we noticed that queries are always making two RPCs per query
(instead of one like it should) to ensure the client has the latest table
metadata. If the above fix is problematic, do you have ideas for a different
fix?
[~tdsilva] - I think we could potentially move the startTx() into
MetaDataClient.updateCache(). If we find the table in the cache, we can check
if it's tranasactional and only then start the transaction. If it's the first
time the table is accessed for that cluster connection, then we can't get away
with a single RPC. Perhaps we can encapsulate this in
MetaDataClient.updateCache()?
Thoughts?
> Only sync table metadata when necessary
> ---------------------------------------
>
> Key: PHOENIX-1812
> URL: https://issues.apache.org/jira/browse/PHOENIX-1812
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
> Assignee: Thomas D'Silva
> Attachments: PHOENIX-1812.patch, PHOENIX-1812.patch
>
>
> With transactions, we hold the timestamp at the point when the transaction
> was opened. We can prevent the MetaDataEndpoint getTable RPC in
> MetaDataClient.updateCache() to check that the client has the latest table if
> we've already checked at the current transaction ID timestamp. We can keep
> track of which tables we've already updated in PhoenixConnection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
