How to prevent race conditions in a web application?

Question

Consider an e-commerce site, where Alice and Bob are both editing the product listings. Alice is improving descriptions, while Bob is updating prices. They start editing the Acme Wonder Widget at the same time. Bob finishes first and saves the product with the new price. Alice takes a bit longer to update the description, and when she finishes, she saves the product with her new description. Unfortunately, she also overwrites the price with the old price, which was not intended.

In my experience, these issues are extremely common in web apps. Some software (e.g. wiki software) does have protection against this - usually the second save fails with "the page was updated while you were editing". But most web sites do not have this protection.

It's worth noting that the controller methods are thread-safe in themselves. Usually they use database transactions, which make them safe in the sense that if Alice and Bob try to save at the precise same moment, it won't cause corruption. The race condition arises from Alice or Bob having stale data in their browser.

How can we prevent such race conditions? In particular, I'd like to know:

• What techniques can be used? e.g. tracking the time of last change. What are the pros and cons of each.
• What is a helpful user experience?
• What frameworks have this protection built in?

Answer 1

You need to "read your writes", which means before you write down a change, you need to read the record again and check if any changes where made to it since you last read it. You can do this field-by-field (fine-grained) or based on a timestamp (coarse-grained). While you do this check you need an exclusive lock on the record. If no changes were made, you can write down your changes and release the lock. If the record has changed in the meantime, you abort the transaction, release the lock and notify the user.

Answer 2

Use Optimistic Concurrency Control.

Add a versionNumber or versionTimestamp column to the table in question (integer is safest).

User 1 reads record:

{id:1, status:unimportant, version:5}

User 2 reads record:

{id:1, status:unimportant, version:5}

User 1 saves record, this increments the version:

save {id:1, status:important, version:5}
new value {id:1, status:important, version:6}

User 2 tries to save the record they read:

save {id:1, status:unimportant, version:5}
ERROR

Hibernate/JPA can do this automatically with the @Version annotation. If you use Spring Data Rest, it will automatically set the HTTP ETag with this version number

You need to maintain the state of the read record somewhere, generally in session (this is safer than in a hidden form variable).

Answer 3

I have seen 2 main ways:

1. Add the timestamp of the last update of the page the use is editing in a hidden input. When committing the timestamp is checked against the current one and if they don't match it has been updated by someone else and return an error.

   • pro: multiple users can edit different parts of the page. The error page can lead to a diff page where the second user can merge his changes in the new page.

   • con: sometime large parts of effort gets wasted during large concurrent edits.

2. When a user starts editing the page lock it for a reasonable amount of time, when another user then tries to edit he gets an error page and has to wait until either the lock expires or the first user has committed.

   • pro: edit efforts are not wasted.

   • con: an unscrupulous user can lock a page indefinitely. A page with an expired lock may still be able to commit unless otherwise dealt with (using technique 1)

Answer 4

Some Object Relational Mapping (ORM) systems will detect which fields of an object have changed since being loaded from the database, and will construct the SQL update statement to only set those values. ActiveRecord for Ruby on Rails is one such ORM.

The net affect is that fields the user didn't change are not included in the UPDATE command sent to the database. People who update different fields at the same time don't overwrite each others changes.

Depending on which programming language you are using, research which ORMs are available, and see if any of them will only update columns in the database marked "dirty" in your application.

Answer 5

Within your example of the webstore, it is crucial that you ensure that two access points are never granted access to the same data point before you commit new changes to the platform or even allow a user to edit the platform.

This means ensuring that the database will not allow multiple users to access the same item at once. There are multiple tools in the space that actually automate this process.

Tools like (Intel Inspector): These tools rely on the data race actually occurring during the profiled execution. Data races are notoriously difficult to detect and debug because they depend on a specific timing to be observed. If the race is not triggered during the execution, these tools will not report the data race.

Coderrect (A company that I am an intern for): Coderrect is working on a data race detector that addresses the limitations of tools like Intel inspector. Our tool, Coderrect Scanner, does not rely on profiling the execution, but scans the source code directly and alerts the developer about any possible races.