Restrictions with AWT Cache Groups

Certain restrictions apply when using an AWT cache group.

The following restrictions apply when using an AWT cache group:

• Only the ON DELETE CASCADE and UNIQUE HASH ON cache table attributes can be used in the cache table definitions.

  See ON DELETE CASCADE Cache Table Attribute.

  See Creating a Hash Index on the Primary Key Columns of the Cache Table.

• A FLUSH CACHE GROUP statement cannot be issued on the cache group.

  See Flushing a User Managed Cache Group.

• The cache table definitions cannot contain a WHERE clause.

  See Using a WHERE Clause.

• A TRUNCATE TABLE statement cannot be issued on the cache tables.

• AWT cache groups cannot cache Oracle Database views or materialized views.

• The replication agent must be stopped before creating or dropping an AWT cache group.

  See Starting and Stopping the Replication Agent.

• Committed changes on the TimesTen cache tables are not propagated to the cached Oracle Database tables unless the replication agent is running.

• To create an AWT cache group, the length of the absolute path name of the TimesTen database cannot exceed 248 characters.

• You should avoid running DML statements on Oracle Database tables cached in an AWT cache group. This could result in an error condition. Any insert, update, or delete operation on the cached Oracle Database table can negatively affect the operations performed on TimesTen for the affected rows. TimesTen does not detect or resolve update conflicts that occur on the Oracle database. Committed changes made directly on a cached Oracle Database table may be overwritten by a committed update made on the TimesTen cache table when the cache table update is propagated to the Oracle database. In addition, deleting rows on the cached Oracle Database table could cause an empty update if TimesTen tries to update a row that no longer exists.

  To ensure that not all data is restricted from DML statements on Oracle Database, you can partition the data on Oracle Database to separate the data that is to be included in the AWT cache group from the data to be excluded from the AWT cache group.

• TimesTen performs deferred checking when determining whether a single SQL statement causes a constraint violation with a unique index.

  For example, suppose there is a unique index on a cached Oracle Database table's NUMBER column, and a unique index on the same NUMBER column on the TimesTen cache table. There are five rows in the cached Oracle Database table and the same five rows in the cache table. The values in the NUMBER column range from 1 to 5.

  An UPDATE statement is issued on the cache table to increment the value in the NUMBER column by 1 for all rows. The operation succeeds on the cache table but fails when it is propagated to the cached Oracle Database table.

  This occurs because TimesTen performs the unique index constraint check at the end of the statement's processing after all the rows have been updated. The Oracle database, however, performs the constraint check each time after a row has been updated.

  Therefore, when the row in the cache table with value 1 in the NUMBER column is changed to 2 and the update is propagated to the Oracle database, it causes a unique constraint violation with the row that has the value 2 in the NUMBER column of the cached Oracle Database table.