Handling a Concurrent Update SituationThere are three approaches to handling a concurrent update situation: - Last commit wins. This is the situation described above, where David wipes out Felicia'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.
- First commit wins. In this scenario, David 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". David's changes would not be saved to the DB. This does require detection of a concurrent update.
- Merge. Here, David 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 him a way of merging his changes with Felicia'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... |