Page History

Example Situation

To set the scene, here's a typical situation in our web applications:

• Dave pulls up data in his browser. Goes to lunch.
• Shahla Felicia pulls up same data, makes a change and saves. Changes are committed to the DB.
• Dave comes back from lunch, changes the data on his screen and saves. Changes are committed, overwriting ShahlaFelicia's changes.

Obviously this isn't good; when Dave finally submits changes, we need the app to detect that someone else has changed the data, and to handle the situation appropriately. Two aspects to doing this are:

1. Detection - how to detect a concurrent update
2. Handling - what to do if we detect a concurrent update

We'll take these in reverse order:

Handling a Concurrent Update Situation

There are three approaches to handling a concurrent update situation:

1. Last commit wins. This is the situation described above, where Dave wipes out ShahlaFelicia's changes. This is what we're doing most of the time in our apps, and it does not involve any detection of a concurrent update.
2. First commit wins. In this scenario, Dave would come back from lunch, attempt to save his changes, and see an error message "Someone else has changed the data. Your changes have not been saved". Dave's changes would not be saved to the DB. This does require detection of a concurrent update.
3. Merge. Here, Dave would be presented with a message telling him that someone else had changed the data, and would be provided with a UI to give them a way of merging his changes with ShahlaFelicia's changes. This does require detection of a concurrent update.

Unless there's a clear business requirement for the merge option, I think we need to take the second approach, "first commit wins". In order to pursue this approach, we do need to have a mechanism for detecting concurrent updates. Which leads to...