1. Introduction
  2. Using TimesTen
  3. Uses for Cache in TimesTen

Uses for Cache in TimesTen

Cache is supported in both TimesTen Scaleout and TimesTen Classic and can be used for read-only or updatable data.

The features for cache in TimesTen are:

  • A read-only cache. Oracle Database data can be cached in a read-only cache group. Read-only cache groups are automatically refreshed when the Oracle database tables are updated. A read-only cache group provides fast access to reference data such as look-up tables and subscriber profiles.

  • An updatable cache. Oracle Database data can be cached in updatable cache groups. Transactions on the cache groups can be committed synchronously or asynchronously to the associated Oracle database tables.

  • A data manager for specific tasks in an overall workflow in collaboration with a file system-based RDBMS like the Oracle Database. For example, a phone billing application may capture and store recent call records in the TimesTen database while storing information about customers, their billing addresses and credit information in an Oracle database. It can also age and keep archives of all call records in the Oracle database. Thus, the information that requires immediate access is stored in the TimesTen database while the information needed for longer-term analysis, auditing, and archival is stored in the Oracle database.

  • A scalable cache. Oracle Database data can be cached in multiple instances of TimesTen running on different machines to provide scalability. You can configure a dynamic distributed cache in which records are loaded automatically and aged automatically.

  • An integrated method for high availability and disaster recovery. TimesTen replication is tightly integrated with cache features enabling customers to deploy highly available cache configurations. Cache functionality also integrates with Oracle Database high availability features such as Oracle RAC and Oracle Data Guard to provide seamless cross-tier high availability and disaster recovery capabilities.

See Caching in TimesTen and Replication.

Cache Application Scenario

One example of using a cache group is a Caller usage metering application that illustrates how a cache group can store metering data on the activities of cellular callers.

A wireless communications company has a usage metering application that keeps track of the duration of each cellular call and the services used. For example, if a caller makes a regular call, a base rate is applied for the duration of the call. If a caller uses special features (like roaming), extra charges are applied.

The usage metering application must efficiently monitor up to 100,000 concurrent calls, gather usage data on each call, and store the data in a central database for use by other applications that generate bills, reports, audits, and so on. Thus, metering data is collected from multiple TimesTen databases distributed throughout a service area and archived in a central Oracle database for use by a central billing application.

The company uses TimesTen databases in an active standby pair to store the caller data that is of immediate interest to the usage metering application and to warehouse all of the other data in the Oracle database. The company distributes multiple instances of the usage metering application on individual nodes throughout its service areas. For maximum performance, each usage metering application connects to its local TimesTen database by an ODBC direct driver connection.

Figure 2-4 shows the configuration.

Figure 2-4 Distributed Caching of Usage Data

Description of Figure 2-4 follows
Description of "Figure 2-4 Distributed Caching of Usage Data"

A usage metering application and a TimesTen database are deployed on each node to handle the processing for calls beginning and terminating at different geographical locations delineated by area code. For each call, the local node stores a separate record for the beginning and the termination of a call. This is because the beginning of a cellular call might be detected by one node and its termination by another node.

Transactions that impact revenue (inserts and updates) must be durable. To ensure data availability, each TimesTen database is configured as an active-standby replicated pair using TimesTen replication.

Each time a customer makes, receives or terminates a cellular call, the application inserts a record of the activity into the Calls table in the TimesTen database. Each call record includes a timestamp, unique identifier, originating host's IP address, and information on the services used.

In this scenario, the CALLS table is configured for write through caching; as data is inserted, updated, or deleted in the table in TimesTen, the changes are automatically propagated (in real-time) to the underlying Oracle database. After the call records have been successfully propagated to the Oracle database, they are deleted from the TimesTen databases (but not from the Oracle database) by an automatic time-based aging process.