A cache group is a collection of one or more cached Oracle tables:
- related to each other by foreign key constraints.
- arranged in a logical hierarchy by using primary key and foreign key relationships.
Data from the Oracle database can be preloaded into a cache group. Depending on the cache group type, an optional WHERE condition can also be specified to restrict or partition the data to be cached.
You can create or modify cache groups by using SQL statements or by using Oracle SQL Developer.
Changes that originate in the Oracle tables are refreshed into the cache by the cache agent.
An Oracle table cannot be cached in separate cache groups within the same TimesTen database. However, the table can be cached in separate cache groups within different TimesTen databases.
Cache groups support these features:
- Applications can read from and write to cache groups.
- Cache groups can be refreshed from Oracle data automatically or manually.
- Updates to cache groups can be propagated to Oracle tables automatically or manually.
- Changes to either Oracle tables or the cache group can be tracked automatically.
IMDB Cache is designed to continue running even after the Oracle Database server or network connection has been lost. Committed transactions to the cache database are tracked and persisted in the transaction log; and once the connection to the Oracle Database is restored, the transactions are propagated to the Oracle Database. Similarly, committed transactions on the source tables in the Oracle Database are tracked and refreshed to the TimesTen database once connection between the databases is re-established.
Each table in a cache group is related to an Oracle database table. A cache table can contain all rows and columns or a subset of the rows and columns in the related Oracle table.
The data in a dynamic cache group is loaded on demand.
For example, a call center application may not want to preload all of its customers' information into TimesTen as it may be very large. Instead it can use a dynamic cache group so that a specific customer's information is loaded only when needed such as when the customer calls or logs onto the system.
Any system managed cache group type (read-only, AWT, SWT) can be defined as a dynamic cache group. A user managed cache group can be defined as a dynamic cache group unless it uses both the AUTOREFRESH cache group attribute and the PROPAGATE cache table attribute.
Tables that are cached in separate cache groups within different TimesTen databases must be cached in global cache groups in order for the cache grid to manage consistency of the cache instances across the grid members when updates are committed on the cache tables of the cache group.
Global cache groups can be defined as dynamic AWT cache groups or as explicitly loaded AWT cache groups.
Read-only cache group specifies the tables cached from the Oracle database are for read operations, updates are done in the Oracle database and refreshed to the cache.
transactions are performed in the Oracle Database and the changes are refreshed to the TimesTen cache database.
For read-only caches, incremental updates in the Oracle Database are asynchronously refreshed to the in-memory cache tables in the application-tier at user-specified intervals.
CREATE READONLY CACHE GROUP "READ_ONLY" AUTOREFRESH MODE INCREMENTAL INTERVAL 5 SECONDS STATE PAUSED FROM "DI_BISAMPLE"."SAMP_CUSTOMERS_D" ( "CUST_KEY" NUMBER NOT NULL, "NAME" VARCHAR2(255 CHAR), "TYPE_KEY" VARCHAR2(255 CHAR), "FST_CONTACT_DT" DATE , "SEGMENT_KEY" NUMBER , "INCOME_LVL" VARCHAR2(255 CHAR), "STATUS_KEY" VARCHAR2(255 CHAR), "LST_ORDER_DT" DATE , "ADDRESS_KEY" NUMBER , "MARITAL_ST" VARCHAR2(20 BYTE) , "PREV_MARITAL_ST" VARCHAR2(20 BYTE) , "PREV_MARITAL_ST_DT" DATE , "BIRTH_DT" DATE , "CRDT_RATE" NUMBER(38) , "GENDER" VARCHAR2(20 BYTE) , "LTV" NUMBER , "NUM_ATTRIBUTE" NUMBER , PRIMARY KEY("CUST_KEY") )
Asynchronous Write-through cache group specifies the tables cached from the Oracle database are for read/write transactions in the cache, committed transactions are asynchronously propagated to the Oracle database.
Any updates that occur in the TimesTen cache table are automatically propagated to the Oracle database.
To enable the propagation of AWT data between the cache tables and the Oracle database, the replication agent must be running.
Asynchronous write-through cache leverages the speed of TimesTen by first committing the transactions locally in the cache database, and asynchronously sending the updates to the Oracle Database. Asynchronous write-through cache groups provide faster application response time and higher transaction throughput.
Synchronous write-through cache will ensure that if the Oracle Database cannot accept the update(s), the transaction is rolled back from the cache database; with synchronous write-through, the application must wait for the commits to complete in both the Oracle Database and the TimesTen database.
On-demand and preloaded cached
Data may be loaded on-demand or preloaded, and may be shared across the cache grid members, or reside only in a specific cache node.
Creating a cache group requires that the cache admin user be set
Creating a cache group requires that the cache admin user be set. Please set it before trying to create a cache group.
When you try to create a cache group with a TT user, you have to set the cache admin user for this user.
Documentation / Reference
- Administering an Active Standby Pair with Cache Groups - replicating of cache tables