Flat Transaction

Problem

How can a client application organize a set of domain model changes to be submitted in a transaction that is easy to implement?

Context

You are developing a client application that commits transactions on an application server.

Forces

Solution

Group all of the changes in a single transaction that has no internal structure. Use the application server's manual transaction mode to open a server transaction at the beginning of the business transaction, make the desired changes, and then commit the server transaction at the end of the business transaction.

Resulting Context

In order to reduce the risk of commit failures, you may want to obtain a write lock for objects that you are changing.

If the client application includes a user interface to a person, you need to consider the consequences of having relatively long transactions. Other models, such as Conversational Transactions, provide a way to limit the use of system resources for long business transactions.

Rationale

This is an easy model to implement, because it assumes that the business transaction can be directly implemented as a server transaction. This model is well understood by developers, as it is commonly used for relational databases.

Related Patterns

For other solutions to this same problem, see the list of patterns for selecting a transaction model.

Variants

Locking objects at the beginning of the transaction is a common way to assure that the commit will be successful.