Db2 Connect and transaction processing monitors
Transaction processing supports interactive applications in which requests are processed as soon as they are received and returned to the requester in a relatively short period of time. You can use Transaction Processing (TP) monitors to process transactions in an organized way.
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.
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).
- 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.
- Data Sharing
- 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, and IBM mainframe database servers and have these transactions coordinated by a TP monitor.
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 Edition.
Examples of transaction processing monitors
- IBM® WebSphere® Application Server
- IBM WebSphere MQ
- IBM TxSeries CICS®
- BEA Tuxedo
- BEA WebLogic
- Microsoft Transaction Server (MTS)
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® for 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 previously listed TP monitors are all XA compliant TMs. Remote host, IBM Power Systems, 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, IBM Power Systems, and LAN-based databases within business applications executing transactions.