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.
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.
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.
Last Commit Wins provides a different solution to this problem by initiating a new server transaction automatically and replaying the user's changes, which may overwrite some of the changes from the first committed transaction.