3 TimesTen Architecture

This chapter includes the following topics:

Architectural overview

The architecture for TimesTen Classic and TimesTen Scaleout are described in the following sections:

Architectural overview of TimesTen Classic and TimesTen Cache

This section describes the architecture of TimesTen Classic and the TimesTen Application-Tier Database Cache (TimesTen Cache). The architecture of TimesTen Classic is the same as the architecture of the TimesTen Cache except that the Oracle database and cache agent are not included. Figure 3-1 shows the architecture of the TimesTen Cache.

Figure 3-1 TimesTen Application-Tier Database Cache architecture

Description of Figure 3-1 follows
Description of ''Figure 3-1 TimesTen Application-Tier Database Cache architecture''

The architectural components include shared libraries, memory-resident data structures, database processes, and administrative programs. The application can connect to the TimesTen database by direct link and by client/server connections.

Replication agents receive information from master databases and send information to subscriber databases. The cache agent performs all asynchronous data transfers between cache groups in the TimesTen Cache and the Oracle database.

See "TimesTen Architecture" for more details on these components.

Architectural overview of TimesTen Scaleout

TimesTen Scaleout enables you to create a grid that is a set of interconnected instances installed on one or more hosts. TimesTen Scaleout enables you to distribute the data of a database across this grid.

  • You can create one or more in-memory, SQL relational, ACID-complaint databases.

    The architectural components for each database include shared libraries, memory-resident data structures, database processes, and administrative programs. The application can connect to the TimesTen database by direct link and by client/server connections. These components are described in subsequent sections.

  • Data instances (in which data is contained and managed) execute SQL statements and PL/SQL blocks. A grid distributes the data within each database across data instances.

  • You create one or two management instances through which the grid is managed. You manage all data instances through the active management instance.

  • Set up a membership service to track which data instances are operational at any moment. The membership service consists of three or more membership servers.

  • You can connect applications to your database with full access to all the data, no matter what the distribution of the data is across the database.

Figure 3-2 TimesTen Scaleout Grid structure

Description of Figure 3-2 follows
Description of ''Figure 3-2 TimesTen Scaleout Grid structure''

See "TimesTen Scaleout architecture" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for full details of the TimesTen Scaleout architecture.

Shared libraries

The routines that implement the TimesTen functionality are embodied in a set of shared libraries that developers link with their applications and execute as a part of the application's process. This shared library approach is in contrast to a more conventional RDBMS, which is implemented as a collection of daemon processes to which applications connect, typically over a client/server network. Applications can also use a client/server connection to access a TimesTen database, though in most cases the best performance can be realized with a directly linked application. See "TimesTen connection options" for more information.

Memory-resident data structures

The TimesTen database resides entirely in main memory at runtime. It is maintained in shared memory regions provided by the operating system and contains all user data, indexes, system catalogs, transaction log buffers, and temporary space. Multiple applications can share one database, and a single application can access multiple databases on the same system.

Database processes

TimesTen initiates separate background processes to each database to perform operations:

TimesTen daemon

The TimesTen daemon performs the following functions:

  • Manage shared memory access

  • Coordinate process recovery

  • Keep management statistics on what databases exist, which are in use, and which application processes are connected to which databases

  • Manage RAM policy

  • Start replication processes (if requested), the TimesTen Server and the cache agent (if enabled).

The TimesTen daemon starts when TimesTen is installed. This main daemon runs in the background. The instance administrator must manually start and stop the daemon after each system reboot or the root user can start the daemon by executing the daemon startup script.

Application developers do not interact with the daemon directly. No application code runs in the daemon and application developers do not generally have to be concerned with it. Application programs that access TimesTen databases communicate with the daemon transparently using TimesTen internal routines.

See "Working with the TimesTen Daemon" in the Oracle TimesTen In-Memory Database Operations Guide for more information.

Subdaemons

The main TimesTen daemon spawns subdaemons dynamically as they are needed. TimesTen uses subdaemons to perform the following:

  • Manage databases

  • Flush the transaction log buffer to disk

  • Perform periodic checkpoints in the background for the active database

  • Load the database into memory from a checkpoint file on disk

  • Implement the data aging policies of various tables

  • Detect and handle deadlocks

  • Roll back transactions for abnormally terminated direct-mode applications

  • Perform required background processing for the database

  • Recover the database if it needs to be recovered after loading it into memory

See "Managing subdaemons" in the Oracle TimesTen In-Memory Database Operations Guide for more information.

TimesTen connection options

TimesTen supports direct, driver manager, and client/server connection options so that users can choose the best tradeoff between performance and functionality for their applications. From an application's perspective, the TimesTen API is identical whether it is a direct connection, driver manager connection, or a client/server connection.

Applications can connect to a TimesTen database in one of the following ways:

For more information about connecting to a TimesTen Classic database, see "Managing TimesTen Databases", "Working with the TimesTen Client and Server" and "Connecting to TimesTen with ODBC and JDBC drivers" in the Oracle TimesTen In-Memory Database Operations Guide.

For details on connecting to a grid using TimesTen Scaleout, see "Database connections" and "Connecting to a database" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

Direct connection

An application using a direct connection runs on the same system as the database. In a direct connection, the ODBC driver attaches the shared memory region of the TimesTen database into the application's process address space. The application then uses the direct driver to access the memory image of the database. Because no inter-process communication (IPC) of any kind is required, a direct connection provides extremely fast performance and is the preferred way for applications to access the TimesTen database.

Applications that use direct connections must run in the environment of the TimesTen instance that provides the database. When using TimesTen Scaleout applications can run in any data instance.

The ODBC direct driver is a library of ODBC and TimesTen routines that implement the database engine used to manage the database. Applications using other APIs use the appropriate API library, which then in turn uses the TimesTen ODBC driver.

Client/server connection

The TimesTen client driver and TimesTen Server daemon processes accommodate connections from remote client machines to databases across a network.

  • Applications on a client machine issue ODBC, JDBC or OCI calls. These calls access a local ODBC client driver that communicates with the TimesTen instance. The TimesTen instance, in turn, issues native ODBC requests to the ODBC direct driver to access the TimesTen database.

  • The TimesTen Server daemon manages incoming connections from remote client applications. Its behavior is much like the TimesTen daemon for local applications, but it allocates a server child process to access the database on behalf of the client.

Traditional client/server access is supported for functions such as reporting, or when a large number of application-tier platforms must share access to a common in-memory database.

All exchanges between client and server are sent over a TCP/IP connection. If the client and server reside on separate hosts in the internal network, they communicate by using sockets and TCP/IP. If both the client and server reside on the same machine, they can communicate more efficiently by using direct connections.

  • Client applications communicate with the TimesTen instance that provides the database.

  • With TimesTen Scaleout, an application using a client/server connection may run on a data instance or on any host with access to the external network. Client applications are automatically connected to a working data instance. For more information, see "Database connections" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

For more information on connecting using ODBC and JDBC interfaces, see "Working with TimesTen Databases in ODBC" in the Oracle TimesTen In-Memory Database C Developer's Guide and "Working with TimesTen Databases in JDBC" in the Oracle TimesTen In-Memory Database Java Developer's Guide.

Driver manager connection

Applications can connect to the TimesTen database through an ODBC driver manager, which is a database-independent interface that adds a layer of abstraction between the applications and the TimesTen database. In this way, the driver manager enables applications to be written to operate independently of the database and to use interfaces that are not directly supported by TimesTen. You can use a driver manager with either direct or client/server connections, which enables a single process to have both direct and client connections to the database.

You can link a client application directly with the TimesTen Client ODBC driver or with the Windows ODBC driver manager to access the TimesTen database. Driver managers for Linux or UNIX systems are available as open-source software as well as from third-party vendors. Driver manager connections can provide support for ODBC applications written for a different ODBC version or for multiple RDBMS products with ODBC interfaces. Note that there are performance considerations in using a driver manager.

See "Connecting to TimesTen with ODBC and JDBC drivers" in the Oracle TimesTen In-Memory Database Operations Guide for more information.

Checkpoint and transaction log files

Checkpoint files contain an image of the database in persistent storage on disk. TimesTen uses dual checkpoint files in case the system fails while a checkpoint operation is in progress. Changes to a database are captured in transaction log files that are periodically written to persistent storage on disk. If a database needs to be recovered, TimesTen merges the most recent database checkpoint file on disk with the completed transactions that are still in the transaction log files.

See "Data Availability and Integrity" for more information.

Cached data

When the TimesTen Cache is used to cache portions of an Oracle database in a TimesTen database, a cache group is created to hold the cached data.

A cache group is a collection of one or more tables arranged in a logical hierarchy by using primary key and foreign key relationships. 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 database table. You can create or modify cache groups by using SQL statements or by using Oracle SQL Developer. Cache groups support these features:

  • Applications can read from and write to cache groups.

  • Cache groups can be refreshed from the Oracle database automatically or manually.

  • Updates to cache groups can be propagated to the Oracle database tables automatically or manually.

  • Changes to either the Oracle database tables or the cache group can be tracked automatically.

When rows in a cache group are updated by applications, the corresponding rows in the Oracle database tables can be updated synchronously as part of the same transaction or asynchronously immediately afterward depending on the type of cache group. The asynchronous configuration produces significantly higher throughput and much faster application response times.

Changes that originate in the Oracle database tables are refreshed into the cache by the cache agent.

See "TimesTen Cache" for more information.

Replication

TimesTen Classic replication enables you to achieve near-continuous availability or workload distribution by sending updates between two or more hosts. A master host is configured to send updates and a subscriber host is configured to receive them. A host can be both a master and a subscriber in a bidirectional replication scheme. Time-based conflict detection and resolution are used to establish precedence in case the same data is updated in multiple locations at the same time.

TimesTen recommends the active standby pair replication scheme configuration for highest availability. It is the only replication configuration that you can use for replicating TimesTen Cache. An active standby pair includes an active database, a standby database, and optional read-only subscriber databases.

When replication is configured, a replication agent is started for each database. Each replication agent can send updates to one or more subscribers and to receive updates from one or more masters. Each of these connections is implemented as a separate thread of execution inside the replication agent process. Replication agents communicate through TCP/IP stream sockets.

For maximum performance, the replication agent detects updates to a database by monitoring the existing transaction log. It sends updates to the subscribers in batches, if possible. Only committed transactions are replicated. On the subscriber host, the replication agent updates the database through an efficient internal interface that avoids the overhead of the SQL layer.

See "Data Replication within TimesTen Classic" for more information about replication configurations.