1. Cache Guide
  2. Methods for Transmitting Changes Between TimesTen and Oracle Databases
  3. Dynamic Cache Groups
  4. Guidelines for Dynamic Load

Guidelines for Dynamic Load

This section details the guidelines for a dynamic load to occur of cache instances for each cache group referenced in the main query.

Note:

Examples for these guidelines are provided in Examples of Dynamic Load of a Single Cache Instance.

Dynamic load of a cache instance is available only for the following types of statements issued on a cache table in a dynamic cache group:

  • When an INSERT statement inserts values into any of the child tables of a cache instance that does not currently exist in the TimesTen tables, the cache instance to which the new row belongs dynamically loads. The insert operation for the new child row is propagated to the cached Oracle Database table.

  • SELECT, UPDATE, or DELETE statements require that the WHERE clause have the conditions as stated in Dynamic Cache Groups.

The SELECT, UPDATE, or DELETE statements for which dynamic load is available must satisfy the following conditions:

  • If the statement contains a subquery, only the cache group with tables referenced in the main query are considered for a dynamic load.

  • If the statement references multiple tables of the cache group, the statement must include an equality join condition between the primary keys and foreign keys for all parent and child relationships.

  • The statement cannot contain the UNION, INTERSECT, or MINUS set operators.

  • The statement can reference non-cache tables.

  • The statement can reference cache tables from only one dynamic cache group.

Dynamic load of a cache instance occurs when you set DynamicLoadEnable=1 and the request passes the following rules:

  • Dynamic load of a cache instance does not occur for a cache group if any table of the cache group is specified more than once in any FROM clause.

  • Only the conditions specified in the query are considered for dynamic load, which excludes any derived conditions.

  • If any cache group is referenced only in a subquery, it is not considered for a dynamic load.

  • When using an active standby pair replication scheme, dynamic load cannot occur in any subscriber.

The following considerations can affect dynamic load:

  • If tables within multiple cache groups or non-cache group tables are specified in the main query, the join order influences if the cache instance is loaded. If during the processing of the query, a dynamic load is possible and necessary to produce the query results, the dynamic load occurs. However, if no rows are returned, then some or all of the cache instances are not dynamically loaded.

  • If a statement specifies more than the dynamic load condition on tables of a cache group, the cache instance may be dynamically loaded even though the additional conditions are not qualified for the statement.

You can use aging with a dynamic cache group. TimesTen supports two aging types, least recently used (LRU) aging and time-based aging. By default, the data in a dynamic cache group is subject to LRU aging. Time-based aging on a dynamic cache group overrides LRU aging. If the cache group has a time-based aging policy defined, the timestamp in the root table's row must be within the aging policy's lifetime in order for the cache instance to be loaded.

Rows in a dynamic AWT cache group must be propagated to the Oracle database before they become candidates for aging.

You can use the ttAgingLRUConfig built-in procedure to override the default or current LRU aging attribute settings for the aging cycle and TimesTen database space usage thresholds. See Implementing Aging in a Cache Group for TimesTen Classic.