[
https://issues.jboss.org/browse/TEIID-3725?page=com.atlassian.jira.plugin...
]
Van Halbert edited comment on TEIID-3725 at 12/16/15 11:58 AM:
---------------------------------------------------------------
There will need to be 3 caches in order to do materialization:
- the primary cache used for reading
- the staging cache to load using materialization
- a cache used for tracking the cache name aliasing that will be used. This will enable
the underlying translator logic to swap out the cache (i.e, primary versus staging) after
the cache that was used for staging is loaded and provide a persistence of the aliasing
when the server is restarted.
Another reason for needing the 3rd cache is that the other caches will be completely
cleared before each materialization. So combining different object types into a cache
wouldn't work at this time.
The configuring of the caches to be used will be done on the connector, along with
configuring the other JDG connection information. I contemplated using translator
overrides for this additional settings, but decided on the connector because the connector
settings are specific and the staging cache settings would be specifically related to that
same cache.
was (Author: van.halbert):
There will need to be 3 caches in order to do materialization:
- the primary cache used for reading
- the staging cache to load using materialization
- a cache used for tracking the cache name aliasing that will be used. This will enable
the underlying translator logic to swap out the cache (i.e, primary versus staging) after
the cache that was used for staging is loaded and provide a persistence of the aliasing
when the server is restarted.
The configuring of the caches to be used will be done on the connector, along with
configuring the other JDG connection information. I contemplated using translator
overrides for this additional settings, but decided on the connector because the connector
settings are specific and the staging cache settings would be specifically related to that
same cache.
In the JDG translators, enable named cache swapping so that
materialization can be supported
--------------------------------------------------------------------------------------------
Key: TEIID-3725
URL:
https://issues.jboss.org/browse/TEIID-3725
Project: Teiid
Issue Type: Feature Request
Components: Misc. Connectors
Affects Versions: 8.12
Reporter: Van Halbert
Assignee: Van Halbert
The JDG translators, that in order to support materialization, will need to enable the
named cache that's referenced by the connection, to be swapped. This is due to JDG
doesn't currently support renaming a cache (i.e., like table rename in JDBC). And
because of that, it limits how the cache can be refreshed (don't want to clear it
before re-loading).
Ideas are:
1. configure translator with the 2 cache names to use (a) initial cache to read from and
(b) the staging cache to use
perform materialize load
call SYSADMIN.setProperty to trigger the swapping of the cache names
2 ???
Note: because there's no persistence in Teiid so that any cache name changes will
outlive a server restart, when a restart occurs, the translator will read from the cache
identified as the initial cache to read from.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)