Posts Tagged ‘lost update problem’

Optimistic and Pessimistic Concurrency Control

March 31, 2010 1 comment

Most web applications allow a user to query a database, retrieve a local copy of the queried data, make changes to that local copy, and then finally send the updates and the unchanged values back to the database.

These are often described as CRUD (Create, Read, Update, Delete) applications. An example would be a simple web registration form which would request from the user their first name, last name, email address, password, and mailing list preferences in order to create a profile on the site. In this scenario, we’ll have a one to one mapping of the user table to the form on a web page. An example of each CRUD operation would be:

  • Create – registering on the site
  • Read – logging in and viewing your profile
  • Update – changing your mailing list preferences
  • Delete – requesting your account be closed. Many times data is not actually deleted from the database, but instead an update is executed to set the status to “inactive”.

In this user profile example, only one person is updating the data (since only one person knows the correct password needed to access the record) so the data in the database is the same between the Read and Update steps. However, there are some web applications where multiple users can modify the same data set concurrently. These applications can suffer from the “lost update” problem.

Lost Update Problem
To illustrate the lost update problem, consider a web application which allows salespeople to maintain a list of clients. This web application allows any salesperson to view a list of clients and then click on any one client to update that client’s information. The user must click the “Save” button to persist their changes to the database.
Read more…