The best (and perhaps only) way of maintaining system consistency and dealing properly with the error-recovery challenge is to use transactions. A transaction is a set of potentially complex operations, in which the failure of any single operation causes the entire set to fail, as one atomic operation. As illustrated in Figure 7-1, while the transaction is in progress the system is allowed to be in a temporary inconsistent state, but once the transaction is complete it is guaranteed to be in a consistent state. That state may be either a new consistent state (B), or the original consistent state the system was in before the transaction started (A).
Figure 7-1. A transaction transfers the system between consistent states
A transaction that executes successfully and manages to transfer the system from the consistent state A to the consistent state B is called a committed transaction. If the transaction encounters an error during its execution and rolls back all the intermediate steps that have already succeeded, it is called an aborted transaction. If the transaction failed to either commit or abort, it is called an in-doubt transaction. In-doubt transactions usually require administrator or user assistance to resolve and are beyond the scope of this book.
Transactional programming requires working with a resource (such as a database or a message queue) ...