[ https://jira.jboss.org/jira/browse/TEIID-444?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIID-444: ------------------------------- Fix Version/s: 6.1.0 Affects Version/s: 6.0.0 To support providing the Cache services at connector level, Teiid will provide following two methods on the "ExecutionContext" interface in the Connector API -- Object getFromCache(CacheScope scope, Object key); -- void storeInCache(CacheScope scope, Object key, Object value); Where CacheScope is defined as public enum CacheScope { REQUEST, // retained until end of every top level request SESSION, // retained until end of user session termination VDB, // retained for life of VDB SERVICE, // retained for life of the service GLOBAL; // common across system, query engine life cycle } except for REQUEST, the items placed in all other scopes will be replicated across the cluster in server mode. In embedded, no replication is available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/TEIID-444?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIID-444: ------------------------------------ one thing I changed in the above API is to change "key" to be "String" type No, it is not the Node, it is the cached object. But irrespective of how it is stored, the way you ask for the is what it matters. For Example, if we store X |--Y |--Z to get the data out, you would say get(X).getData("a"); get(X/Y).getData("a"); get(X/Y/Z).getData("a"); even in flat hierarchy you can store as X X/Y X/Y/Z you get the data you can call get(X) get(X/Y) get(X/Y/Z) so, all it matters is how you are relatively you are using your keys to for your purpose. In both cases you need to be aware of the node location. I wanted to keep the Cache API to be simple to use at Connector level, so that it is trivial to used by any connectors, otherwise we would have expose the internals of Cache API, which seems unnecessary. There is no administration by the user, the connector developer uses the cache based on it's scopes, once the scope expires the cache will expire automatically. Centrally in the server, there will be configuration to control the cache items, based on events generated server, a manager object will expire the items as they happen. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/TEIID-444?page=com.atlassian.jira.plug... ] Ramesh Reddy resolved TEIID-444. -------------------------------- Resolution: Done Small deviation from the original interface, but the "getFromCache" and "storeInCache" calls moved to ConnectorEnvironment interface, and ExecutionContext interface now has Object get(Object key); void set(Object key, Object value); which places a object in the REQUEST scope. Since ExecutionContext is only available in the REQUEST scope, these changes were necessary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira