DB2 Connect and transaction processing monitors

 

An application server permits a large number of users to execute applications using a minimum of system resources. An application server can be extended to allow coordinated transactions to be invoked from applications executed by the application server. This transaction coordination is generally known as a Transaction Processing (TP) monitor. A TP monitor works in conjunction with an application server.

A transaction can be thought of as a routine event, usually a request for service, in running the day-to-day operations of an organization. The orderly processing of transactions is the type of work for which TP monitors were designed.

Transaction processing

Every organization has rules and procedures that describe how it is supposed to operate. The user applications which implement these rules can be called business logic. The transactions these business applications execute are often referred to as Transaction Processing or Online Transaction Processing (OLTP).

The key characteristics of commercial OLTP are:

Many Users

It is common for transaction processing to be used by the majority of the people in an organization, since so many people affect the current state of the business.

Repetitive

Most interactions with the computer tend to be the same process executed over and over again. For example, entering an order or processing payments are used many times every day.

Short Interactions

Most interactions that people in the organization have with the transaction processing system are short in duration.

Shared Data

Since data represents the state of the organization, there can only be a single copy of the data.

Data Integrity

The data must represent the current state of the organization, and must be internally consistent. For example, every order must be associated with a customer record.

Low Cost/Transaction

Since the transaction processing represents a direct cost of doing business, the cost of the system must be minimal. DB2 Connect™ allows applications under the control of an application server running on Linux™, UNIX®, and Windows® to execute transactions against remote LAN, host, and System i™ database servers and have these transactions coordinated by a TP monitor.

Figure 1. DB2 Connect support for TP monitors

This figure shows DB2 Connect Support for TP Monitors

In Figure 1, the APIs, as well as the connectivity mechanism between the application server and the back-end database servers, are provided by a DB2 Connect server product, such as DB2 Connect Enterprise Server Edition.

Examples of transaction processing monitors

The most common TP monitors on the market today are:

Remote System i, zSeries®, and LAN database servers can be used within transactions coordinated by these TP monitors.

X/Open Distributed Transaction Processing (DTP) model

An application executing business logic might be required to update multiple resources within a single transaction. For example, a bank application which implements a transfer of money from one account to another could require debiting one database (the "from" account) and depositing to another database (the "to" account).

It is also possible that different vendors provide these two databases. For example, one database is a DB2 Universal Database™ for OS/390® and z/OS® and the other is an Oracle database. Rather than have every TP monitor implement each database vendor's proprietary transaction interface, a common transaction interface between a TP monitor and any resource accessed by an application has been defined. This interface is known as the XA Interface. A TP monitor that uses the XA Interface is referred to as an XA compliant Transaction Manager (TM). An updatable resource that implements the XA interface is referred to as an XA compliant Resource Manager (RM).

The above listed TP monitors are all XA compliant TMs. Remote host, System i, and DB2® LAN-based databases, when accessed via DB2 Connect, are XA compliant RMs. Therefore, any TP monitor which has an XA compliant TM can use host, System i, and LAN-based DB2 databases within business applications executing transactions.

Parent topic: DB2 Connect scenarios

Related concepts
X/Open distributed transaction processing model Security considerations for XA transaction managers Configuration considerations for XA transaction managers XA function supported by

Related tasks
Updating host or System i database servers with an XA-compliant transaction manager