Resolving conflicts between transactions

First Commit Wins


How can you serialize a set of changes from overlapping business transactions that affect the same object when your primary concern is for users to see changes immediately as they occur?


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. It is essential that users are aware of each other's changes to busines objects.



A transactional application server allows the first server transaction to "win" in the sense that successive transactions having a write-write conflict will fail. Whenever a client application experiences a commit failure, abort the transaction, and refresh the user's view from the current state of the server. This will cause the user to lose all of their changes, forcing them to start a new business transaction. They will need to reevaluate the new data manually in order to decide whether to redo their changes or not.

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.

Since there is no attempt to preserve the user's changes that cause the conflict, it is not necessary to represent the user's changes independently of the view.


This is a very easy pattern to implement. While it sounds terrible to cause the end user to redo their work, this may be acceptable when the probability of a commit failure is so low that it can be ignored.

Related Patterns

Resolving conflicts between transactions