| Pattern Name | Problem | Solution |
|---|---|---|
| Flat Transaction | How can a client application organize a set of domain model changes to be submitted in a transaction that is easy to implement? | Group all of the changes in a single transaction that has no internal structure. |
| Chained Transaction | How can a client application organize a set of domain model changes to be submitted in a series of transactions while holding locks across transaction boundaries? | Commit the work of a Flat Transaction and then remain in a transaction, while holding previous locks. |
| Conversational Transaction | 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? | Perform one transaction to read data, process the data offline, and then submit the changes in a new transaction. |
| Queued Transaction | How can a client application organize a set of domain model changes to be submitted in a transaction where there are many clients adding new independent data? | Specify the actions to be performed in a transaction and submit that specification into the queue of a transaction processor. |
| Nested Transaction | How can a client application organize a set of domain model changes to be submitted in a transaction where the changes are organized in hierarchical increments? | Provide a nested structure of transactions, so that each embedded transaction can be rolled back without affecting higher level transactions. |
| Distributed Transaction | How can a client application organize a set of domain model changes to be submitted in a transaction where the domain model is distributed across more than one server? | Provide a two-phase commit process, where each server verifies that it can commit its portion of the transaction before any server performs its portion of the commit. |