Defining transactions in a client application

Dirty Object Pool

Problem

How can a client application record a change to a domain model object independently from that object?

Context

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.

Forces

Solution

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.

Resulting Context

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.

Rationale

There are several advantages to this solution:

  1. Changes to persistent objects can be made outside of a server transaction, which allows you to implement long business transactions with short server transactions.

  2. 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.

Related Patterns


Defining transactions in a client application