Product SiteDocumentation Site

Chapter 2. Transactions Overview

2.1. What is a transaction?
2.2. The Coordinator
2.3. The Transaction Context
2.4. Participants
2.5. Commit protocol
2.6. The Synchronization Protocol
2.7. Optimizations to the Protocol
2.8. Non-Atomic Transactions and Heuristic Outcomes
2.9. Interposition
2.10. A New Transaction Protocol
2.10.1. Addressing the Problems of Transactioning in Loosely Coupled Systems

2.1. What is a transaction?

Note

This chapter deals with the theory of transactional services. If you are familiar with these principles, consider this chapter a reference.
Consider the following situation: a user wishes to purchase access to an on-line newspaper and requires to pay for this access from an account maintained by an on-line bank. Once the newspaper site has received the user’s credit from the bank, they will deliver an electronic token to the user granting access to their site. Ideally the user would like the debiting of the account, and delivery of the token to be “all or nothing” (atomic). However, hardware and software failures could prevent either event from occurring, and leave the system in an indeterminate state.
  • Atomic transactions (transactions) possess an “all-or-nothing” property, and are a well-known technique for guaranteeing application consistency in the presence of failures. Transactions possess the following ACID properties:
  • Atomicity: The transaction completes successfully (commits) or if it fails (aborts) all of its effects are undone (rolled back).
  • Consistency: Transactions produce consistent results and preserve application specific invariants.
  • Isolation: Intermediate states produced while a transaction is executing are not visible to others. Furthermore transactions appear to execute serially, even if they are actually executed concurrently.
  • Durability: The effects of a committed transaction are never lost (except by a catastrophic failure).
A transaction can be terminated in two ways: committed or aborted (rolled back). When a transaction is committed, all changes made within it are made durable (forced on to stable storage, e.g., disk). When a transaction is aborted, all of the changes are undone. Atomic actions can also be nested; the effects of a nested action are provisional upon the commit/abort of the outermost (top-level) atomic action.
Transactions have emerged as the dominant paradigm for coordinating interactions between parties in a (distributed) system, and in particular to manage applications that require concurrent access to shared data. A classic transaction is a unit of work that either completely succeeds, or fails with all partially completed work being undone. When a transaction is committed, all changes made by the associated requests are made durable, normally by committing the results of the work to a database. If a transaction should fail and is rolled back, all changes made by the associated work are undone. Transactions in distributed systems typically require the use of a transaction manager that is responsible for coordinating all of the participants that are part of the transaction.
The main components involved in using and defining transactional applications are:
  • A Transaction Service: The Transaction Service captures the model of the underlying transaction protocol and coordinates parties affiliated with the transaction according to that model.
  • A Transaction API: Provides an interface for transaction demarcation and the registration of participants.
  • A Participant: The entity that cooperates with the transaction service on behalf of its associated business logic.
  • The Context: Captures the necessary details of the transaction such that participants can enlist within its scope.