[ https://issues.apache.org/jira/browse/PHOENIX-3823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maddineni Sukumar updated PHOENIX-3823: --------------------------------------- Attachment: PHOENIX-3823.v9.patch Created new patch as old patch did not apply properly due to other latest commits. > Force cache update on MetaDataEntityNotFoundException > ------------------------------------------------------ > > Key: PHOENIX-3823 > URL: https://issues.apache.org/jira/browse/PHOENIX-3823 > Project: Phoenix > Issue Type: Sub-task > Affects Versions: 4.10.0 > Reporter: James Taylor > Assignee: Maddineni Sukumar > Fix For: 4.11.0 > > Attachments: PHOENIX-3823.patch, PHOENIX-3823.v2.patch, > PHOENIX-3823.v3.patch, PHOENIX-3823.v4.patch, PHOENIX-3823.v5.patch, > PHOENIX-3823.v6.patch, PHOENIX-3823.v7.patch, PHOENIX-3823.v8.patch, > PHOENIX-3823.v9.patch > > > When UPDATE_CACHE_FREQUENCY is used, clients will cache metadata for a period > of time which may cause the schema being used to become stale. If another > client adds a column or a new table or view, other clients won't see it. As a > result, the client will get a MetaDataEntityNotFoundException. Instead of > bubbling this up, we should retry after forcing a cache update on the tables > involved in the query. > The above works well for references to entities that don't yet exist. > However, we cannot detect when some entities are referred to which no longer > exists until the cache expires. An exception is if a physical table is > dropped which would be detected immediately, however we would allow queries > and updates to columns which have been dropped until the cache entry expires > (which seems like a reasonable tradeoff IMHO. In addition, we won't start > using indexes on tables until the cache expires. -- This message was sent by Atlassian JIRA (v6.3.15#6346)