{@link de.qfs.lib.transaction.Transaction 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 {@link de.qfs.lib.transaction.Commitable Commitables} in a Transaction, the interdependence of the objects and methods is moved out of the objects themselves and into the Transaction.