The best (or 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, you are guaranteed to be in a consistent state, either a new consistent state (B) or the original consistent state the system was at before the transaction started (A).
Figure 7-1. A Transaction transfers the system between consistent states
If the transaction executed successfully, and managed to transfer the system from the consistent state A to the consistent state B, it is called a committed transaction. If the transaction encountered any error during its execution and rolled 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 that ...