1 TimesTen Application-Tier Database Cache Concepts

Overview of a cache grid

A cache grid is a set of distributed TimesTen in-memory databases that work together to cache data from an Oracle database and guarantee cache coherence for global cache groups among the TimesTen databases. Use a cache grid only if you plan on using global cache groups.

A grid consists of one or more in-memory database grid members that collectively manage the application data using the relational data model. The members of a grid cache data from a single Oracle database. A grid member can be either a standalone TimesTen database or an active standby pair.

A grid node is the database for a grid member. A node is one of the following:

• A standalone TimesTen database

• The active master database in an active standby pair

• The standby master database in an active standby pair

Thus, a grid member that is a standalone database consists of one node. A grid member that is an active standby pair consists of two nodes.

Figure 1-1 shows a cache grid containing three members: two standalone TimesTen databases and an active standby pair. The grid has four nodes: the two standalone TimesTen databases, the active master database and the standby master database of the active standby pair. The read-only subscriber database is not part of the cache grid because it has no connectivity with the Oracle database. The read-only subscriber receives replicated updates from the standby master database.

Figure 1-1 Cache grid with three grid members caching data from an Oracle database

Description of "Figure 1-1 Cache grid with three grid members caching data from an Oracle database"

In a cache grid, global cached data is dynamically distributed across multiple grid members without shared storage. This architecture enables the capacity of the cache grid to scale based on the processing needs of the application. When the workload increases or decreases, new grid members attach to the grid or existing grid members detach from the grid. Attaching to or detaching from the grid are online operations that do not interrupt operations on other grid members.

When requests are submitted to the grid members, the cache grid automatically redistributes data based on application access patterns. The location of the data is transparent to the application, but the cache grid redistributes data dynamically to minimize access time. The cache grid automatically maintains cache coherence and transactional consistency across the grid members. You can also configure the cache grid to perform global queries without redistributing the data. See "Performing global queries on a cache grid".

TimesTen databases within a cache grid can contain explicitly loaded and dynamic cache groups, as well as local and global cache groups of any cache group type that is supported for the various cache group classifications and categories. Although cache coherence is only managed for global cache groups.

See "Cache group types" for details about the different types of cache groups.

See "Loading data into a cache group: Explicitly loaded and dynamic cache groups" for details about the differences between an explicitly loaded and a dynamic cache group.

See "Sharing data across a cache grid: Local and global cache groups" for details about the differences between a local and a global cache group.

See "Configuring a cache grid" for information about creating a cache grid and associating a TimesTen database with a cache grid.

Cache instance

Data is loaded from an Oracle database into a cache group within a TimesTen database in units called cache instances. A cache instance is defined as a single row in the cache group's root table together with the set of related rows in the child tables.

Figure 1-3 shows three tables in the customer_orders cache group. The root table is customer. orders and order_item are child tables. The cache instance identified by the row with the value 122 in the cust_num primary key column of the customer table includes:

• The two rows with the value 122 in the cust_num column of the orders table (whose value in the ord_num primary key column is 44325 or 65432), and

• The three rows with the value 44325 or 65432 in the ord_num column of the order_item table

Figure 1-3 Multiple-table cache group

Description of "Figure 1-3 Multiple-table cache group"

Cache group types

The most commonly used types of cache groups are:

• Read-only cache group

  A read-only cache group enforces a caching behavior in which committed updates on cached tables in the Oracle database are automatically refreshed to the cache tables in the TimesTen database. Using a read-only cache group is suitable for reference data that is heavily accessed by applications.

  See "Read-only cache group" for details about read-only cache groups.

• Asynchronous writethrough (AWT) cache group

  An AWT cache group enforces a caching behavior in which committed updates on cache tables in the TimesTen database are automatically propagated to the cached tables in the Oracle database in asynchronous fashion. Using an AWT cache group is suitable for high speed data capture and online transaction processing.

  See "Asynchronous writethrough (AWT) cache group" for details about AWT cache groups.

Other types of cache groups include:

• Synchronous writethrough (SWT) cache group

  An SWT cache group enforces a caching behavior in which committed updates on cache tables in the TimesTen database are automatically propagated to the cached tables in the Oracle database in synchronous fashion.

  See "Synchronous writethrough (SWT) cache group" for details about SWT cache groups.

• User managed cache group

  A user managed cache group defines customized caching behavior.

  For example, you can define a cache group that does not use automatic refresh or automatic propagation where committed updates on the cache tables are manually propagated or flushed to the cached Oracle Database tables.

  You can also define a cache group that uses both automatic propagation in synchronous fashion on every table and automatic refresh.

  See "User managed cache group" for details about user managed cache groups.

Transmitting updates between the TimesTen and Oracle databases

Transmitting committed updates between the TimesTen cache tables and the cached Oracle Database tables keeps these tables in the two databases synchronized.

As shown in Figure 1-4, propagate and flush are operations that transmit committed updates on cache tables in the TimesTen database to the cached tables in the Oracle database. Flush is a manual operation and propagate is an automatic operation.

Load, refresh, and autorefresh are operations that transmit committed updates on cached tables in the Oracle database to the cache tables in the TimesTen database. Load and refresh are manual operations; autorefresh is an automatic operation.

See "Flushing a user managed cache group" for information about the FLUSH CACHE GROUP statement which can only be issued on a user managed cache group.

See "Asynchronous writethrough (AWT) cache group" and "Synchronous writethrough (SWT) cache group" for details about how a propagate operation is processed on AWT and SWT cache groups, respectively.

See "Loading and refreshing a cache group" for information about the LOAD CACHE GROUP and REFRESH CACHE GROUP statements.

See "AUTOREFRESH cache group attribute" for details about an autorefresh operation.

Figure 1-4 Transmitting committed updates between the TimesTen and Oracle databases

Description of "Figure 1-4 Transmitting committed updates between the TimesTen and Oracle databases"

Loading data into a cache group: Explicitly loaded and dynamic cache groups

Cache groups are categorized as either explicitly loaded or dynamic.

In an explicitly loaded cache group, cache instances are loaded manually into the TimesTen cache tables from an Oracle database by using a load or refresh operation or automatically by using an autorefresh operation. The cache tables are loaded before operations such as queries are performed on the tables. An explicitly loaded cache group is appropriate when the set of data to cache is static and can be predetermined before applications begin performing operations on the cache tables. By default, cache groups are explicitly loaded unless they are defined as dynamic.

In a dynamic cache group, cache instances are loaded into the TimesTen cache tables on demand from an Oracle database using a dynamic load operation or manually using a load operation. A manual refresh or an autorefresh operation on a dynamic cache group can result in existing cache instances being updated or deleted, but committed updates on Oracle Database data that are not being cached do not result in new cache instances being loaded into its cache tables. A dynamic cache group is appropriate when the set of data to cache is small and should not be preloaded from Oracle Database before applications begin performing operations on the cache tables.

See "Transmitting updates between the TimesTen and Oracle databases" for details about cache group load and refresh operations.

See "Loading and refreshing a cache group" for more details about the differences between performing a load and a refresh operation on an explicitly loaded cache group and performing the same operations on a dynamic cache group.

See "Dynamically loading a cache instance" for details about a dynamic load operation.

Any cache group type (read-only, AWT, SWT, user managed) can be defined as an explicitly loaded cache group. All cache group types except a user managed cache group that uses both the AUTOREFRESH cache group attribute and the PROPAGATE cache table attribute can be defined as a dynamic cache group.

See "Dynamic cache groups" for more information about dynamic cache groups.

Sharing data across a cache grid: Local and global cache groups

In addition to being explicitly loaded or dynamic, cache groups are also classified as either local or global.

In a local cache group, data in the cache tables is not shared across TimesTen databases even if the databases are members of the same cache grid. Therefore, the databases can have overlapping data because the cache instances are local to a specific grid member. Committed updates on the TimesTen cache tables are propagated to the cached Oracle Database tables without coordination with other grid members. Any cache group type can be defined as a local cache group. A local cache group can be defined either as explicitly loaded or dynamic. Using a local cache group is suitable for reference data that is read frequently and can be present in all grid members and for disjoint data that is logically partitioned for optimal concurrency and throughput. By default, cache groups are local unless they are defined as global.

In a global cache group, data in its cache tables are shared across TimesTen databases that are members of the same cache grid. Committed updates to the same data on different grid members are propagated to the Oracle database in the order in which they were issued within the grid to ensure read/write data consistency across the members of the grid.

A dynamic AWT cache group and an explicitly loaded AWT cache group can be defined as global cache groups. New cache instances are loaded into the cache tables of a global cache group on demand. Queries on a dynamic AWT global cache group can be satisfied by data from the local grid member on which the query is made, from remote grid members, or from the Oracle database. Queries on an explicitly loaded AWT cache group can be satisfied by data from the local grid member or from remote grid members. Using a global cache group is suitable for updatable data that can only be accessed by or present in one grid member at a time in order to ensure that the data is consistent among both the members of the grid and the Oracle database.

See "Global cache groups" for information about creating and using a global cache group.

Summary of cache group types

The table in Figure 1-5 summarizes the valid combinations of cache group types, categories and classifications available to the user at cache group creation time. The cache group categories determine how the data is loaded into the cache group. The cache group classifications determine whether data in the cache group can be shared across a cache grid.

You can create an explicitly loaded local cache group or a dynamic local cache group of any cache group type. You can create a global cache group for a cache group whose category and type is dynamic AWT or explicitly loaded AWT.

Figure 1-5 Summary of cache group types and categories

Description of "Figure 1-5 Summary of cache group types and categories"