...
To set the scene, here's a typical situation in our web applications:
- User A Dave pulls up data in their his browser. Goes to lunch.
- User B Shahla pulls up same data, makes a change and saves. Changes are committed to the DB.
- User A Dave comes back from lunch, changes the data on their his screen and saves. Changes are committed, overwriting User BShahla's changes.
Obviously this isn't good; when User A 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:
...
- Last commit wins. This is the situation described above, where User A Dave wipes out User BShahla'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, User A Dave would come back from lunch, attempt to save their his changes, and see an error message "Someone else has changed the data. Your changes have not been saved". User ADave's changes would not be saved to the DB. This does require detection of a concurrent update.
- Merge. Here, User A Dave would be presented with a message telling them him that someone else had changed the data, and would be provided with a UI to give them a way of merging their changes with User BShahla's changes. This does require detection of a concurrent update.
...
What we want to do is to detect any changes in the database that occurred between the data-retrieval step (step 1) and the data-posting step (step 2) (i.e. while Dave is at lunch). For this to happen, step 2 needs to know what the version field was in step 1. So far I've read about three techniques for doing this:
...