How can a client application record a change to a domain model object independently from that object?
You are developing a client application and you want to record changes to server objects in a transaction specification, so that the changes can be preserved across transaction boundaries. For example, you might want to replay changes after aborting a transaction.
Keep a copy of the object in its changed state, where the copy is local to the client and is unaffected by transaction boundaries in the application server.
As a result of adopting this solution, the client application is able to replay changes across transaction boundaries. Therefore after an abort, data from the non-persistent copies of domain objects can be copied into persistent domain objects within a transaction, in order to redo the desired changes. This solution also supports a conversational transaction model in which the change specification is built outside of a transaction and then replayed inside of a transaction to cause the changes to be persistent.
There are several advantages 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.
Compared to the Aspect Change Specification pattern, this solution requires quite a bit of overhead, because copies of the persistent object graph must be maintained in non-persistent objects outside of the view of the repository. It is easy to maintain a copy of a single object, but for an entire graph, the references between objects must also be maintained.
Aspect Change Specification is an alternative to this Dirty Object Pool solution. It is another way to record a specification of changes to domain objects, so that changes can be replayed in a new transaction.
Last Commit Wins and Merge Conflicting Updates provide specific strategies for replaying changes.