7 Event Notification

TimesTen and IMDB Cache event notification is done through the Transaction Log API (XLA), which provides functions to detect changes to the database. XLA monitors log records. A log record describes an insert, update or delete on a row in a table. XLA can be used with materialized views to focus the scope of notification on changes made to specific rows across multiple tables.

TimesTen and IMDB Cache also use SNMP traps to send asynchronous alerts of events.

This chapter includes the following topics:

Transaction Log API

TimesTen and IMDB Cache provide a Transaction Log API (XLA) that enables applications to monitor the transaction log of a local database to detect changes made by other applications. XLA also provides functions that enable XLA applications to apply the detected changes to another database. XLA is a C language API. TimesTen and IMDB Cache provide a C++ wrapper interface for XLA as part of TTClasses, as well as a separate Java wrapper interface.

Applications use XLA to implement a change notification scheme. In this scheme, XLA applications can monitor a database for changes and then take actions based on those changes. For example, a TimesTen database in a stock trading environment might be constantly updated from a data stream of stock quotes. Automated trading applications might use XLA to "watch" the database for updates on certain stock prices and use that information to determine whether to execute orders. See "Real-time quote service application" for a complete example.

XLA can also be used to build a custom data replication solution in place of the TimesTen replication. Such XLA-enabled replication solutions might include replication with a non-TimesTen database or pushing updates to another TimesTen database.

How XLA works

XLA obtains update records for transactions directly from the transaction log buffer. If the records are not present in the buffer, XLA obtains the update records from the transaction log files on disk, as shown in Figure 7-1. Records are available as long as the transaction log files are available. Readers use bookmarks to maintain their position in the log update stream. Bookmarks are stored in the database, so they are persistent across database connections, shutdowns, and failures.

Figure 7-1 How XLA works

Description of Figure 7-1 follows
Description of "Figure 7-1 How XLA works"

XLA also operates in nonpersistent mode. In nonpersistent mode, XLA obtains update records from the transaction log buffer and stages them in an XLA staging buffer. After records are read by the application from the staging buffer, they are removed and are no longer available. XLA in nonpersistent mode does not use bookmarks.

Log update records

Update records are available to be read from the log as soon as the transaction that created them commits. A "log sniffer" application can obtain groups of update records written to the log.

Each returned record contains a fixed-length update header and one or two rows of data stored in an internal format. The update header describes:

  • The table to which the updated row applies

  • Whether the record is the first or last commit record in the transaction

  • The type of transaction it represents

  • The length of the returned row data

  • Which columns in the row were updated

Materialized views and XLA

In most database systems, materialized views are used to simplify and enhance the performance of SELECT queries that involve multiple tables. Though materialized views offer this same capability in TimesTen and IMDB Cache, another purpose of materialized views in TimesTen and IMDB Cache is their role in working with XLA to keep track of specific rows and columns in multiple tables.

When a materialized view is present, an XLA application needs to monitor only update records that are of interest from a single materialized view. Without a materialized view, the XLA application would have to monitor all of the update records from all of the detail tables, including records reflecting updates to rows and columns of no interest to the application.

Figure 7-2 shows an update made to a column in a detail table that is part of the materialized view result set. The XLA application monitoring updates to the materialized view captures the updated record. Updates to other columns and rows in the same detail table that are not part of the materialized view result set are not seen by the XLA application.

Figure 7-2 Using XLA to detect updates on a materialized view table

Description of Figure 7-2 follows
Description of "Figure 7-2 Using XLA to detect updates on a materialized view table"

See "Real-time quote service application" for an example of a trading application that uses XLA and a materialized view to detect updates to select stocks.

The TimesTen and IMDB Cache implementation of materialized views emphasizes performance as well as the ability to detect updates across multiple tables. Readers familiar with other implementations of materialized views should note that the following tradeoffs have been made:

  • The application must explicitly create materialized views. The TimesTen query optimizer has no facility to create materialized views automatically.

  • The query optimizer does not rewrite queries on the detail tables to reference materialized views. Application queries must directly reference views.

  • There are some restrictions to the SQL used to create materialized views.

When creating a materialized view, the application must specify whether the maintenance of the view should be immediate or deferred. With immediate maintenance, a view is refreshed as soon as changes are made to its detail tables. With deferred maintenance, a view is refreshed only after the transaction that updated the detail tables is committed. A view with deferred maintenance is called an asynchronous materialized view. The refreshes may be automatic or may be initiated by the application, and they may be incremental or full. The application must specify the frequency of automatic refreshes. Note that the order of XLA notifications for an asynchronous materialized view is not necessarily the same as the order of transactions for the associated detail tables.

SNMP traps

Simple Network Management Protocol (SNMP) is a protocol for network management services. Network management software typically uses SNMP to query or control the state of network devices like routers and switches. These devices sometimes also generate asynchronous alerts in the form of UDP/IP packets, called SNMP traps, to inform the management systems of problems.

TimesTen and IMDB Cache cannot be queried or controlled through SNMP. However, TimesTen and IMDB Cache send SNMP traps for certain critical events to facilitate user recovery mechanisms. TimesTen sends traps for the following events:

  • IMDB Cache autorefresh failure

  • Database out of space

  • Replicated transaction failure

  • Death of daemons

  • Database invalidation

  • Assertion failure

These events also cause log entries to be written by the TimesTen daemon, but exposing them through SNMP traps allows properly configured network management software to take immediate action.

For more information

For more information about XLA, see "XLA and TimesTen Event Management" in Oracle TimesTen In-Memory Database C Developer's Guide and "Using JMS/XLA for Event Management" in Oracle TimesTen In-Memory Database Java Developer's Guide.

For more information about TTClasses, see Oracle TimesTen In-Memory Database TTClasses Guide.

For more information about materialized views, see "Understanding materialized views" in Oracle TimesTen In-Memory Database Operations Guide. Also see the CREATE MATERIALIZED VIEW statement in Oracle TimesTen In-Memory Database SQL Reference.

For more information about SNMP traps, see "Diagnostics through SNMP Traps" in Oracle TimesTen In-Memory Database Error Messages and SNMP Traps.