1. Cache Guide
  2. Defining Cache Groups
  3. User Managed Cache Group
  4. PROPAGATE Cache Table Attribute

PROPAGATE Cache Table Attribute

The PROPAGATE cache table attribute can be specified only for cache tables in a user managed cache group.

PROPAGATE specifies that committed changes on the TimesTen cache table as part of a TimesTen transaction are automatically and synchronously propagated to the cached Oracle Database table. If the PROPAGATE cache table attribute is not specified, then the default setting for a cache table in a user managed cache group is the NOT PROPAGATE cache table attribute (which does not propagate committed changes on the cache table to the cached Oracle table).

All SQL statements run by an application on cached tables are applied to the cached tables immediately. All of these operations are buffered until the transaction commits or reaches a memory upper limit. At this time, all operations are propagated to the tables in the Oracle database.

Note:

If the TimesTen database or its daemon fails unexpectedly, the results of the transaction on either the TimesTen or Oracle databases are not guaranteed.

Since the operations in the transaction are applied to tables in both the TimesTen and Oracle databases, the process for committing is as follows:

  1. After the operations are propagated to the Oracle database, the commit is first attempted in the Oracle database.

    • If an error occurs when applying the operations on the tables in the Oracle database, then all operations are rolled back on the tables on the Oracle database. If the commit fails in the Oracle database, the commit is not attempted in the TimesTen database and the application must roll back the TimesTen transaction. If the user tries to run another statement, an error displays informing them of the need for a roll back. As a result, the Oracle database never misses updates committed in TimesTen.

  2. If the commit succeeds in the Oracle database, the commit is attempted in the TimesTen database.

    • If the transaction successfully commits on the Oracle database, the user's transaction is committed on TimesTen (indicated by the commit log record in the transaction log) and notifies the application. If the application ends abruptly before TimesTen informs it of the success of the local commit, TimesTen is still able to finalize the transaction commit on TimesTen based on what is saved in the transaction log.

    • If the transaction successfully commits on the Oracle database and a failure occurs before returning the status of the commit on TimesTen, then no record of the successful commit is written into the transaction log and the transaction is rolled back.

    • If the commit fails in TimesTen, an error message is returned from TimesTen indicating the cause of the failure. You then need to manually resynchronize the cache tables with the Oracle Database tables.

      Note:

      See Synchronous WriteThrough (SWT) Cache Group for information on how to re-synchronize the cache tables with the Oracle Database tables.

You can disable propagation of committed changes on the TimesTen cached tables to the Oracle database with the ttCachePropagateFlagSet built-in procedure. This built-in procedure can enable or disable automatic propagation so that committed changes on a cache table on TimesTen for the current transaction are never propagated to the cached Oracle Database table. You can then re-enable propagation for DML statements by resetting the flag to one with the ttCachePropagateFlagSet built-in procedure. After the flag is set back to one, propagation of committed changes to the Oracle database resumes. The propagation flag automatically resets to one after the transaction is committed or rolled back. See ttCachePropagateFlagSet in the Oracle TimesTen In-Memory Database Reference.

The following restrictions apply when using the PROPAGATE cache table attribute:

  • If the cache group uses the AUTOREFRESH cache group attribute, the PROPAGATE cache table attribute must be specified on all or none of its cache tables.

    See Automatically Refreshing a Cache Group for more information about using the AUTOREFRESH cache group attribute.

  • If the cache group uses the AUTOREFRESH cache group attribute, the NOT PROPAGATE cache table attribute cannot be explicitly specified on any of its cache tables.

  • You cannot use both the PROPAGATE and READONLY cache table attributes on the same cache table.

    See READONLY Cache Table Attribute for more information about using the READONLY cache table attribute.

  • A FLUSH CACHE GROUP statement cannot be issued on the cache group unless one or more of its cache tables use neither the PROPAGATE nor the READONLY cache table attribute.

    See Flushing a User Managed Cache Group for more information about the FLUSH CACHE GROUP statement.

  • After the PROPAGATE cache table attribute has been specified on a cache table, you cannot change this attribute unless you drop the cache group and re-create it.

  • The PROPAGATE cache table attribute cannot be used when caching Oracle Database materialized views.

  • TimesTen does not perform a conflict check to prevent a propagate operation from overwriting data that was updated directly on a cached Oracle Database table. Therefore, updates should only be performed directly on the TimesTen cache tables or the cached Oracle Database tables, but not both.