The application program (AP) defines transaction boundaries, and specifies the application-specific actions that make up the transaction.
For example, a CICS* application program might want to access resource managers (RMs) such as a database and a CICS Transient Data Queue, and use programming logic between these accesses to manipulate the data. Each access request is passed to the appropriate resource managers through function calls specific to that RM. In the case of DB2, these could be function calls generated by the DB2 precompiler for each SQL statement, or database calls coded directly by the programmer using the APIs.
A transaction manager product usually includes a transaction processing (TP) Monitor to run the user's application. The TP Monitor provides APIs to allow an application to start and end a transaction, and to perform application scheduling and load balancing among the many users who want to run the application. Therefore the application program (AP) in a DTP environment is really a combination of both the user application and the TP monitor.
To facilitate an efficient online transaction processing (OLTP) environment, the TP Monitor pre-allocates a number of server processes at startup, and then schedules and reuses them among the many user transactions. This saves on the amount of system resources by allowing more concurrent users to be supported with a smaller number of server processes and their corresponding RM processes. Reusing these processes also avoids the overhead of starting up a process in the TM and RMs for each user transaction or program. (A program invokes one or more transactions.) This also means the server processes are the actual "user processes" to the TM and the RMs. This has implications for security administration and application programming. See "Security Considerations" for details.
The following types of transactions are possible from a TP Monitor:
These transactions involve RMs that are not defined to the TM, and are therefore not coordinated under the two-phase commit protocol of the TM. This might be necessary if the application needs to access an RM that does not support the XA interface. The user basically just uses the TP monitor as a mechanism that provides efficient scheduling of applications and load balancing. Since the TM does not explicitly "open" the RM for XA processing, the RM treats this application as any other application that runs in a non-DTP environment.
These transactions involve RMs that are defined to the TM, and are under the TM's two-phase commit control. A global transaction is a unit of work that could involve one or more RMs. A transaction branch is the part of work between a TM and an RM to support the global transaction. A global transaction could have multiple transaction branches when multiple RMs are accessed through one or more application processes that are coordinated by the TM.
Loosely coupled, global transactions exist when each of a number of application processes accesses the RMs as if they are in a separate global transaction, but those applications are under the coordination of the TM. Each application process will have its own transaction branch within an RM. When a commit or rollback is requested by any one of the APs, TM, or RMs, the transaction branches are completed altogether. It is the application's responsibility to ensure that resource deadlock does not occur among the branches. (Note that the transaction coordination performed by the DB2 transaction manager for applications prepared with the SYNCPOINT(TWOPHASE) option is roughly equivalent to these global, loosely-coupled transactions. See "Updating Multiple Databases".)
Tightly coupled global transactions exist when multiple application processes take turns to do work under the same transaction branch in an RM. To the RM, the two application processes are treated as a single entity. The RM must ensure that resource deadlock does not occur within the transaction branch.