How can a client application organize a set of domain model changes to be submitted in a transaction where the user needs a relatively long time to specify the changes, but the server prefers short transactions?
You are developing a user interface for a multi-user application that commits transactions on an application server. People using the system perform business transactions that typically take a few minutes, but which may remain open for an arbitrarily long time (e.g. the user opens a customer screen and then goes to lunch before saving the data that has been entered).
Let the user perform the business transaction outside of a server transaction. At the completion of the business transaction, open a server transaction, apply the accumulated changes, and commit the transaction. The client performs the following steps:
In order to apply this pattern, one must have a way of saving changes that are made outside of a transaction, so that they can be reapplied inside of a transaction. The Replay Changes pattern provides a solution to this problem.
For long business transactions where objects must be locked for an extended period of time, the Check Out Objects pattern provides a way to lock objects while minimizing the use of server resources.
One of the advantages of this solution is that it provides a way to handle long business transactions with a server that prefers short transactions. By using short server transactions, the application reduces the resource requirements placed on the server, resulting in better performance.
For other solutions to this same problem, see the list of patterns for selecting a transaction model.
Replay Changes provides a way of saving changes that are made outside of a transaction, so that they can be reapplied inside of a transaction.
Check Out Objects provides a way to lock objects for an extended period of time while minimizing the use of server resources.