8 Event Notification

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 also use SNMP traps to send asynchronous alerts of events.

This chapter includes the following topics:

Detect transaction modifications with the Transaction Log API

TimesTen Classic provides a Transaction Log API (XLA) that enables applications to monitor the transaction log of a 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 Classic provides 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 monitor the database for updates on certain stock prices and use that information to determine whether to execute orders. See "TimesTen Classic application scenario" 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 involve replicating data to a non-TimesTen database.

For more information about XLA, see "XLA and TimesTen Event Management" in the 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 "Using TTClasses XLA" in the Oracle TimesTen In-Memory Database TTClasses Guide.

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 8-1. 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. As described in "When are transaction log files deleted?", the presence of an XLA bookmark prevents transaction log files from being deleted until the XLA log records in that transaction log file have been read and acknowledged by the XLA application.

Log update records

Update records are available to be read from the log as soon as the transaction that created them commits. A log monitoring 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

Monitor tables with 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, another purpose of materialized views in TimesTen Classic is their role in working with XLA to keep track of specific rows and columns in multiple tables.

Note:

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.

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 the detail tables of that materialized view, including records reflecting updates to rows and columns of no interest to the application.

Figure 8-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 columns and rows in the same detail table that are not part of the materialized view are not seen by the XLA application.

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

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

See "TimesTen Classic application scenario" for an example of a trading application that uses XLA and a materialized view to detect updates to specific stocks.

The TimesTen 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.

Monitor problems with 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 cannot be queried or controlled through SNMP. However, TimesTen sends SNMP traps for certain critical events to facilitate user recovery mechanisms.

  • TimesTen 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 enables properly configured network management software to take immediate action.

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