[
https://issues.apache.org/jira/browse/PHOENIX-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301473#comment-15301473
]
Andrew Purtell commented on PHOENIX-2941:
-----------------------------------------
Over in HBase we have ZK based notifications like proposed here for propagating
cache updates of security related information. However we want to replace them
with a Procedure based solution. The trouble with ZK is an given peer can lag
behind the leader by an arbitrary amount of time. In practice the lag may be
small but still. A Procedure provided a guaranteed global synchronization point
(or rollback if we fail to achieve it).
> Alternative means of propagating schema changes
> -----------------------------------------------
>
> Key: PHOENIX-2941
> URL: https://issues.apache.org/jira/browse/PHOENIX-2941
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Nick Dimiduk
>
> The current approach to propagating schema changes (ie, add column) involves
> maintaining a
> [GlobalCache|https://github.com/apache/phoenix/blob/10909ae502095bac775d98e6d92288c5cad9b9a6/phoenix-core/src/main/java/org/apache/phoenix/cache/GlobalCache.java]
> of table schema on both clients and in RS coprocessors. This schema
> information is versioned, and query timestamp is used to determine when the
> cache is considered stale and needs updated. This causes problems for users
> who specify a timestamp either via connection settings (ie, PHOENIX-2607) or
> using the ROW_TIMESTAMP feature. Presumably this will also negatively impact
> users of the Tephra transaction system as it uses the cell timestamp to store
> transaction id.
> We need some other means of propagating schema changes throughout the
> cluster. One approach might be a ZK node for each table that can notify
> coprocessors (and clients?) that their cache is stale.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
