[
https://issues.apache.org/jira/browse/PHOENIX-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14570085#comment-14570085
]
James Taylor commented on PHOENIX-1812:
---------------------------------------
I don't think that's quite right. You'd still want to return the PTable from
PMetaData, even if the txnReadPointer is different. Otherwise, we'll pull it
over from the server all the time instead of the server just responding that we
have the most recent table.
Instead, you need to either add a resolvedTime to PTable or instead of
returning a PTable, return a PTableRef that surfaces this. Then, in
updateCache, you'd exit early if resolvedTime == currentTxnTime or resolvedTime
== currentSCN (as you know you've already got the latest as of that timestamp.
I'm not sure if we want to use the tx read pointer or the tx write pointer.
It's a corner case (as I think they're usually the same), but in the case of
upsert/select over the same table, we'll need to increment the write pointer.
If the schema of the table happened to change as of the old write pointer, I
think we'd want to map the data being written to that new schema now. We'll
need to think through this a bit. What do you think?
> 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
>
>
> 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)
