Transaction

Pattern Properties

Type: Concurrency

Level: Architectural

Purpose

To group a collection of methods so that they either all succeed or they all fail collectively.

Introduction

In object-oriented programming, you are usually dealing with multiple instances of multiple classes. Sometimes, however, you must treat multiple objects as though they were a single object—at least, you must ensure that state remains consistent among objects as an operation is performed.

One example is transferring funds from one account to another. The tasks of removing money from one account and adding it to another account should both be performed, or neither should be performed. The end results should always be in balance: the amount deducted from the first must be added to the second and vice versa. If the deduction from the first account fails (the first account is already over its limit) the second account should not be increased.

If you simply trust that every operation is successful, transferring funds would be very easy and very risky. If the transfer fails, you might see funds magically disappear from one of your accounts—a Bad Thing from your perspective. You might also see funds magically appear on another account—a Good Thing for you, but the banks consider this a Very Bad Thing. Invoking a series of methods in a situation like this should either completely succeed or completely fail.

This is where the Transaction is needed. It makes sure that all participants fail or succeed collectively. How the participants deal with success or failure is up to the individual implementation.

Applicability

Transaction should be used when:

Several methods need to fully synchronized

A recovery option should be available

Description

For some tasks, multiple parts of an application must cooperate. When a single part of that task fails, all of its parts should fail. The combined methods inside the task need to fail or succeed unanimously. If any one participant fails to do its part, all participants should fail, and all participants should return to the state they had before that task started.

The solution to this situation is the Transaction pattern. Every participant in the transaction tries to accomplish its task. The transaction manager is informed when one of the tasks fails. The manager then informs all the participants to revert back to their original state. The transaction manager can be just any object as long as it knows all the participants (directly or indirectly).

After all participants have reported to the transaction manager success in updating, the transaction manager tells all the participants to commit their changes. Commit means that the temporary state they have kept is now the permanent state.

If any participant fails, the manager cancels the transaction and calls the cancel method on each participant. The participants revert back to their previous state they had before the transaction started. This roll-back, as it is also known, can also occur when the transaction manager decides to cancel the transaction even without a failing participant. The result is the same—the transaction is called and rolled back.

178