Resolving conflicts between transactions

Merge Conflicting Updates


How can you serialize a set of changes from overlapping business transactions that affect the same object when your primary concern is that users should not have to reenter any data?


You are developing a multi-user application that commits transactions on an application server. Two or more transactions may overlap while trying to update the same object.



A transactional application server allows the first server transaction to "win" in the sense that successive transactions having a write-write conflict will fail. However, it is possible for the second client to abort the failed transaction, begin a new transaction, replay the changes, and commit the new transaction. While replaying the changes, you must check each individual change to determine whether there is a conflict with the first committed transaction. If so, prompt the user to determine whether or not the new change should be applied.

Resulting Context

Changes from other transactions can only be introduced at transaction boundaries, so the amount of work affected by updating a view will depend on the transaction model that has been chosen.

In order to provide the ability to replay changes, there must be a way to define transaction specifications in the client.


This solution identifies the server transaction conflict to the user, enabling the user to make the necessary adjustments to merge the two sets of changes appropriately. It minimizes the amount of rework that the end user must do, in order to complete their business transaction.

Related Patterns

Resolving conflicts between transactions