Java Reference
In-Depth Information
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.
