Transaction processing monitors.

Transaction Processing MONITORS

Atransaction processing (TP) application is a program that performs an administrative function by accessing a shared database on behalf of an on-line user N TP system is an integrated set of products that supports PP applications. These products includes both hardware such as processors memories, disks and communications controllers and software, such as operating systems (OS), database management systems (DBMS) computer networks, and TP monitors. Much of the integration of these products is provided by TP monitors which coordinance the flow of transaction request between terminals that issue request and TP applications that can process them.

Today, TP represents over 25 percent of the computer systems market and is one of the latest growing segments of the computer business. TP applications appear in most sectors of large enterprises such as airline reservation, electronic banking, securities trading, inventory and production control, communications switching videotex, sales management, militar command and control and government services.

Transactions

A transaction is a unit of work that executes exactly once and produce permanent results. That is, transactions should be

* serializable--the system should appear to process transactions serially;

* all-or-nothing--each transaction should either execute in its entirety or have no effect; and

* persistent--the effects of a transaction should be resistant to failures.

A "user-oriented request" may require executing several transactions. For example, to process an order, a user may enter the order, request a shipment, and issue a bill, each of which may execute as a transaction. To simplify the discussion, this article assumes that a user-oriented request executes as one transaction.

To ensure serializability, all-or-nothing, and persistence, the system requires application programmers to delimit the boundary of each transaction, (e.g., by bracketing the corresponding application program with the Start-transaction and End-transaction operations). The programmer can cause the system to obliterate an active transaction by issuing the Abort-transaction operation. At execution time, each transaction either commits (it executes in its entirely and its results persist) or aborts (its effects are undone).

Most of the system's support for serializability, all-or-nothing, and persistence is within DBMSs. Each DBMS uses concurrency control (usually locking) to make its execution serializable. It uses recovery mechanisms (usually logging) to make transactions all-or-nothing and persistent, by undoing the effects of transactions that do not finish, and by writing all of a transaction's updates to the log before the transaction commits.

If multiple DBMSs are accessed by a single transaction, then additional DBMS coordination is needed, often with TP monitor or OS support, via the two-phase commit protocol: To ensure all-or-nothingness despite failures, the first phase of two-phase commit requires every DBMS accessed by a transaction to put that transaction's updates on stable storage (e.g., disk). After all DBMSs acknowledge phase one, each DBMS is told to commit the transaction.

Concurrency control, recovery, and two-phase commit mechanisms are well-documented in the literature, and are not discussed further in this article (see [4]).

A typical TP application contains relatively few transaction types--sometimes less than ten, usually less than a few hundred. The resources required by a transaction can cover a broad range. Typically, it uses up to 30 disk accesses, up to a few million machine language instructions, and up to a few dozen network messages. Today's largest TP systems have about 100,000 terminals and 1000 disks, and can sustain several thousand transactions per second at peak load. Many TP systems, large and small, are distributed, consisting of multiple nodes that can process transactions.

The TP Computing Style

Most of the attention on TP technology in the technical literature has focused on database aspects of TP. Although database are quite important to TP, the database view of TP is incomplete, because performance and ease-of-use are also much affected by the OS and its integration with communications.

Unless a computing platform is specifically designed for TP (and few of them are), there are likely to be many inefficiencies and inconveniences in implementing TP applications. The reason is that TP is a style of computing different from other standard computing models: batch processing, time-sharing, and real-time. Most importantly, TP systems support the transaction abstraction, which is absent from the other three models. The transaction is the basic unit of computation, different from the "process" or "task" abstraction supported by the underlying OS. TP differs in other ways too.

In classical batch processing, a batch of sorted transaction requests is merged with an input master file to produce a new master file. TP differs from classical batch processing in its need to support a large number of terminals and active users, associative and random access to files, and fine-grain failure handling.

In classical time-sharing, a user logs in from a terminal and executes a sequence of requests that is unpredictable from the system's viewpoint. TP differs from time sharing in the regularity of its application load, the intensity of database management and communications over computation, and its requirement for very high availability.

In real-time systems, fast response time is the main goal. Due to its on-line response time requirements, TP is essentially a database-intensive real-time system that supports the transaction abstraction.

TP Monitors

Through the early 1970s, building a TP system was a roll-your-own activity. Computer vendors supplied hardware, an OS, and sometimes a DBMS, although often the latter could not meet the response time requirements of TP. The vendor's system was usually designed for batch, time sharing, or real-time. The customer had to modify it into a platform suitable for TP.

Today's customers expect far more. The vendor must supply a full complement of integrated basic software, including a high-performance DBMS, communications system, and TP monitor. Application builders expect the TP monitor to offer a seamless integration of the basic software. The TP monitor should manage processes, should provide an interprocess communication abstraction that hides networking details, and should help system managers efficiently and easily control large networks of processors and terminals. In this sense, a TP monitor is a combination of "glue" and "veneer"--glue that ties together independent components and a veneer that provides a single, integrated interface to those components.

There are several ways to structure a TP monitor to provide these functions [2]. In the following section, a model for these structures is presented. All TP monitors of which the author is aware conform to this model. The functions of each component are discussed in the section entitled "TP Monitor Functions." A major aspect of TP monitor functionality is the way it maps the model's components into OS structures. This is described in the section entitled "Process Management." Queuing functions that provide fault-tolerant message passing are described in the "Queuing" section, followed by a discussion of system management and application recovery in the section entitled "System Management and Recovery." The article concludes by showing how distributed computing features of new OSs are subsuming traditional TP monitor functions, and how TP monitors are likely to evolve as a result.

Throughout the article, it is explained why vendors choose one structure over another, using popular commercial products as examples, such as Digital's …