In a distributed computer network, it is sometimes necessary to ensure that a set of separate operations is either all completed, or that none of the operations is completed. In application programming, it is possible to achieve such semantics by using transactions. Systems that require transactions generally rely on a transaction processing service in which the service coordinates multiple operations simultaneously.
The transaction processing services that are described in this overview provide transaction coordination for distributed systems. Very broadly, a transaction is defined as an activity that makes changes to the state of a set of resources so that either all the changes are completed or none of the changes are completed. Resources can be data, such as rows in a database, or logical entities, such as the execution state of a program. Resources that are changed by a transaction can also be in separate systems.
Achieving this under all expected and unexpected conditions is difficult but there is a well-established solution, as described in [GRAY]. The solution identifies three participants in the transaction execution:
These participants communicate with each other by using the Two-Phase Commit Protocol (section 1.1.2). The transaction manager and the resource manager (RM) are usually provided as part of an operating system or other platform elements, such as a database, leaving most implementers with only the application to write.
The RM represents the resources that are involved in the transaction. A transaction manager coordinates the transaction, keeping all of the participants in step. All the changes to the resources that are involved in a transaction are made by applications via implementation-specific protocols outside the scope of the two-phase commit protocol. Only one of the applications that are involved in the transaction initiates and completes the transaction, through communications with its transaction manager. This application is known as the root application. As other participants are added to the transaction, each participant is said to be enlisted in the transaction.
For more information about transaction processing concepts, see [GRAY] chapter 2.1, and [MS-DTCO] section 1.3.