Java Reference
In-Depth Information
To identify a transaction, a transaction ID may be used, either some arbitrary long or object. The benefit to using
an object as ID over a long is that an object can contain information and behavior, the long doesn't contain
behavior but it is smaller. And sending a long over a network is very much less expensive than sending an object.
The normal sequence to use a transaction is:
Create a transaction ID (either as object or long)
Invoke join on all participants and abort the transaction if the joining fails for any of the participants.
Try the action, invoke the necessary business methods and call cancel as soon as any participant fails.
When the action is completed, call commit on all participants.
Implementation
Figure 4.11. Transaction class diagram
The Transaction pattern needs:
TransactionParticipant -
The interface that defines the methods to control every participant.
SpecificParticipant -
As an extension to the generic interface, this interface contains the business methods.
All methods involved in the transaction take an ID as parameter. Methods involved in transaction can throw
Exceptions
as a signal of failure.
ConcreteParticipant -
Implements
SpecificParticipant
interface. It defines what happens if the
transaction manager (in this case, client) decides to roll-back or commit. It has to keep a reference to the original
state to be able to restore it when cancel is invoked.
Client -
Acts as transaction manager. The client calls the join method on the participants to start the transaction
and ultimately calls either cancel or commit on the participants.
Benefits and Drawbacks
The obvious benefit of this pattern is that several methods can be combined to act as one atomic operation. The
result is that the application will always have a consistent state. The new state will not be persisted until all
participants have succeeded in their actions.
The drawback is that this setup will decrease performance. When an object is already involved in a transaction
and the join method is called again to start another transaction, the object has to decide what to do. The most
common choice is to throw an exception at the caller of the join method, which states that it is currently involved.
The transaction manager can either roll-back the second transaction or wait until the participant becomes
available.
