1. Introduction
  2. Using TimesTen
  3. Uses for TimesTen Classic

Uses for TimesTen Classic

TimesTen Classic provides a memory-optimized relational database that gives applications the best response time and high throughput.

TimesTen Classic:

  • Can be used for a single-instance environment and database.

  • Can be used to create one or more in-memory, SQL relational, ACID-complaint databases.

  • Supports high availability for the in-memory database through transactional replication.

TimesTen Classic Application Scenario

A Quote service application is an example of a TimesTen Classic scenario. This quote service illustrates how TimesTen Classic can be integrated as part of a data management solution.

A financial services company is adding a quote and news service to its online trading facility. The quote service reads an incoming news wire from a major market data vendor and make a subset of the data available to trading applications that manage the automated trading operations for the company. The company plans to build an infrastructure that can accommodate future expansion to provide quotes, news, and other trading services to retail subscribers.

The quote service application uses the database to store stock quotes from a data feed for access by program trading applications. Quote data is collected from the data feed and published on a message bus. The data is read from the message bus and stored in the database, where it is accessed by the program trading applications.

The quote service includes a NewsReader process that reads incoming data from a message bus that is constantly fed data from a news wire. Each NewsReader is paired with a backup NewsReader that independently reads the data from the bus and inserts it into a separate database. In this way, the message bus is used to fork incoming data to two databases for redundancy. In this scenario, forking the data from the message bus is more efficient than using TimesTen replication.

One NewsReader makes the stock data available to a trading application, while the other serves as a hot standby backup to be used by the application if a failure occurs. The current load requires four NewsReader pairs, but more NewsReader pairs can be added in the future to scale the service to deliver quotes to other types of clients over the Web or cellular phone.

Figure 2-2 shows the configuration for capturing data from a message bus and feeding it to NewsReaders.

Figure 2-2 Capturing Feed Data From a Message Bus

Description of Figure 2-2 follows
Description of "Figure 2-2 Capturing Feed Data From a Message Bus"

As shown in Figure 2-3, the NewsReader updates stock price data in a QUOTES table in the database. Less dynamic earnings data is updated in an EARNINGS table. The STOCK columns in the QUOTES and EARNINGS tables are linked through a foreign key relationship.

The purpose of the trading application is to track only those stocks with PE ratios below 50, then use internal logic to analyze the current stock price and trading volume to determine whether to place a trade using another part of the trading facility. For maximum performance, the trading application implements an event facility that uses the Transaction Log API (XLA) to monitor the transaction log for updates to the stocks of interest. See Detect Transaction Modifications With the Transaction Log API.

To provide the fastest possible access to such updates, the company creates a materialized view, named PE_ALERTS, with a WHERE clause that calculates the PE ratio from the PRICE column in the QUOTES table and the EARNS column in the EARNINGS table. By using the XLA event facility to monitor the transaction log for price updates in the materialized view, the trading application receives alerts only for those stocks that meet its trading criteria.

Figure 2-3 Using Materialized Views and XLA

Description of Figure 2-3 follows
Description of "Figure 2-3 Using Materialized Views and XLA"