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

Hi,
>> 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.
This is a classic question that you can find in any developing exam :-)
there are several options according the behavior that fit your needs, and several points that need to be taken into consideration.
1.  Using locking in the application side, you can make sure that two people do not open the same product for editing. this is in most cases the best option.
* I am not talking about
thread-safe but the implementation is almost the same. The locking can be done using singleton class and have a static boolean element. Every time a user want to edit we check this value as first action. If the value is false then we lock the and
change it to true -> do what ever we need -> change the value to false -> unlock.
Behavior: First person that try to edit lock the product and the second get a message that this product is unders editing. In this case you do not open connection to database and your application prevent any problem.
2. Using "read your writes", as mentioned
Behavior: this mean that several people can open the same product for editing, and only when they try to send it to server they get a message telling them that they have waist their
time and someone else already change the product information. At this point they have two option: (1) overwrite what the other person did, (2) start from the beginning.
This is the way most WIKI websites work.
3. Using real-time web functionality like SignalR, WebSocket, or any streaming for example. In this case you can send the person that work on the edit a message like "this product have already been edit" and stop give him the extra time to
think what you want to do. You will need to use one of the above option maybe, but since the user get the information in real time he have time to chose.
4. Using "Change before Write" or "read before edit": The idea is to have a column that point if the row is in use. the type of this column should be same as the user unique column type. Before the user start you check the value
of this column. If it is 0 then you change it to the user unique value (for example user_id), If the value was not 0 then you know that someone else is editing the product. In this case the locking is managed in the database. make sure that you work with transactions
while reading the value and changing it! you can change the default from share lock to X lock as well during this action, if you really want.
There are several other option, if those do not fits your needs
  Ronen Ariely
 [Personal Site]    [Blog]    [Facebook]