How can a client application preserve a user's changes after aborting a transaction?
You are developing a multi-user application that commits transactions on an application server. There are several reasons why you might want to be able to replay a user's business transaction after aborting a server transaction:
If a transaction fails, you need to abort the transaction to get a clean view of the repository. However, rather than losing the user's changes, you would like to be able to attempt the transaction again.
For long business transactions, it may be desirable to change persistent objects while outside of a server transaction. However, changes to persistent objects can only be saved in the repository while in a transaction. Therefore, you might want to allow the user to modify an object outside of a transaction, then replay the changes inside of a transaction.
The client keeps the changes independent from the view of the repository, so that when a view is refreshed, the changes may be replayed.
In order to be able to replay changes, you need to be able to identify the changes that were made as part of the current business transaction, as explained in the Transaction Specification pattern.
Two different strategies for replaying changes are described in:
There are two benefits to this solution:
Changes to persistent objects can be made outside of a server transaction, which allows you to implement long business transactions with short server transactions.
You do not lose a user's changes when a commit failure occurs.
Transaction Specification provides a record of changes, so that they can be replayed.
Aspect Change Specification is a way to record user-initiated changes to domain objects which must be replayed.
Dirty Object Pool is another way to record changes to domain objects, so that the changes can be copied into a new transaction.
Last Commit Wins and Merge Conflicting Updates provide specific strategies for replaying changes.