How can you serialize a set of changes from overlapping business transactions that affect the same object?
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.
In order to provide the ability to replay changes, there must be a way to define transaction specifications in the client.
This is an easy pattern to implement, as long as there is a way to define transaction specifications in the client. At first glance, this solution appears to violate the objectives of a transactional system, since the second transaction may overwrite the effects of the first transaction. However, as long as appropriate business rules validate changes as they are played back, there is no risk of changing the repository into an inconsistent state.
One of the disadvantages of this solution is that the software automatically resolves the conflict without notifying the end user that a conflict occurred. In situations where such notification is important or manual merging of changes is more appropriate, then the First Commit Wins or the Merge Conflicting Updates patterns are more appropriate.
The disadvantages of this solution may be acceptable when the probability of a commit failure is so low that it can be ignored or where commit failures typically do not have business consequences. For example, suppose a customer service organization changes addresses and other customer contact information, while a billing organization updates a customer's purchasing information. It is possible that the application server may report a conflict between a customer service transaction and a billing transaction, while from a business perspective the two transactions are updating different aspects of the customer object.
First Commit Wins provides a different solution to this problem by forcing the user to start a new business transaction, starting from the updated object that results from the first committed transaction.
Merge Conflicting Updates provides a different solution to this problem by allowing the replay of changes in the last transaction to selectively update the conflicting object.