|
qflib 0.98.0 | ||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Interface Summary | |
Commitable | A Commitable serves as a placeholder for an action that is either delayed until it is safe to execute, or that can be undone. |
StateHolder | The StateHolder interface is used by CommitableStateChange to make the change of an Object's state
part of a Transaction . |
Class Summary | |
CommitableNotify | A CommitableNotify delays the notification of an Observable's Observer to the time of commit. |
CommitableStateChange | As part of a Transaction the CommitableStateChange
tells a StateHolder when to save and restore
its state. |
IntTests | Integration tests for the transaction package. |
Transaction | Transaction instances allow actions to be collected and executed together
by commit or to be undone together by rollback . |
Exception Summary | |
FatalTransactionException | A FatalTransactionException can be thrown by a Commitable . |
OpenTransactionException | An OpenTransactionException is thrown, when a Transaction is created for a Thread that already has an open
Transaction. |
A simple transaction mechanism that supports commit and rollback on the client side.
Transactions
handle the
common problem, where a complex action depends on a sequence of simple
actions of which either all or none must be executed and some can
possibly fail. Typical situations that call for rollback handling are
client/server or database applications, where just about everything
can go wrong, but also simple things like adding a set of objects to a
list in sorted order, where the insertion of some objects is allowed to
fail.
In such a situation it is very useful to have a common mechanism to handle rollbacks on the client side. As an example, imagine a client/server application where some data is edited in a dialog on the client. When the user finishes and commits his action, the data must be read from the edit dialog and stored in a local object. The server must be notified of the change and, if the call succeeds, local data in the client must be updated and possibly multiple views must be notified to update their display.
The problem here is that the order in which these steps are carried
out is crucial and that the objects and methods that are part of the
complex action depend on each other in order to handle failures
correctly. If these methods can be kept independent, they may also be used
in different contexts to build other complex actions. By collecting
Commitables
in a
Transaction, the interdependence of the objects and methods is moved
out of the objects themselves and into the Transaction.
|
qflib 0.98.0 | ||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |