CODEWITHSUNDEEP
databaseweb-applicationsconcurrencyrace-condition
Ming
Ming

Reputation: 1693

How do I deal with concurrent changes in a web application?

Here are two potential workflows I would like to perform in a web application.

Variation 1

Variation 2:

In each of these cases, I am wondering: what are the standard approaches to ensuring that concurrent access to this service will produce sane results? (i.e. nobody's edit gets clobbered, values correspond to some ordering of the edits, etc.)

The situation is hypothetical, but here are some details of where I would likely need to deal with this in practice:

I feel like I would prefer not to try and reinvent the wheel here. Surely these are well known problems with well known solutions. Please advise.

Thanks.

Upvotes: 9

Views: 7271

Answers (4)

Stian Jørgensrud
Stian Jørgensrud

Reputation: 1024

To answer the question in the title. There are two general solutions for dealing with the lost update problem over HTTP.

Let's assume your application consists of two components; a front end and an API back end. And there are two concurrent users that tries to perform an update on the same data.

1. Optimistic concurrency control

Implement some way of knowing which data has been updated last. Some common ways:

  • Using an ETag. This could be a field stored in db, but could also be computed on each update.
  • Using a LastUpdated timestamp field stored in db
  • Using a Version field stored in db

The ways mentioned above can be combined with the use of conditional HTTP headers. Can be useful if your server framework supports it out of the box.

Example:

  1. User 1 makes a GET request. User 2 makes the same GET request and retrieves the same data.
  2. User 2 updates the data in a PUT request.
  3. User 1 makes a PUT request and get error message. This is because the API back-end compared the ETag on the incoming data (from user 1) and ETag on data in db (from user 2) and ETags mismatched. Meaning we know user 1 didn't have the latest changes when sending the PUT request.

2. Pessimistic concurrency control

Use (pessimistic) database locks.

Example: User 1 makes a GET request. User 2 makes the same GET request and gets an error. This is because we cannot give out potentially outdated data so the information has been locked by db.

There are big downsides with this approach.

  • User 2 cannot read or update that data for a long time. And user 1 hasn't even done an update.
  • An alternative could be to use db transactions. A GET request begins a transaction, and it ends when the user makes a POST request or leaves the site. This could allow for more concurrency.
  • Pessimistic concurrency control requires the API back end to know when user 1 is no longer viewing some data on the front end. This is difficult. Communication probably happens over HTTP which is stateless. If I were to guess on a solution, it could be to use Websockets to maintain a stateful connection with user 1 to monitor which data she is viewing and editing. (And of course there are downsides)

Change your API

One can change the API so it doesn't have the lost update problem.

@jay has already mentioned delta updates as a solution. Let's say one have a number field in a model that should be incremented by 1 on each request. One implementation is a PUT endpoint which updates the model and field with the incoming number. This API has the lost update problem. Another implementation is to have an increment endpoint. This API doesn't have the lost update problem. (The API is RESTful if you view an increment as a resource and create new increments with POST).

Another way is to change the API from PUT to PATCH. This is not a solution, but it will minimise the possibility for lost updates.

Conclusion

Use optimistic concurrency control.

When Googling "lost update problem" one might only get results about databases. Although this is the same problem, database locking is not a good solution for lost concurrent updates over HTTP. It has several downsides compared to optimistic concurrency control, as written above.

Upvotes: 3

Jay
Jay

Reputation: 27474

To the best of my knowledge, there is no general solution to the problem.

The root of the problem is that the user may retrieve data and stare at it on the screen for a long time before making an update and saving.

I know of three basic approaches:

  1. When the user reads the database, lock the record, and don't release until the user saves any updates. In practice, this is wildly impractical. What if the user brings up a screen and then goes to lunch without saving? Or goes home for the day? Or is so frustrated trying to update this stupid record that he quits and never comes back?

  2. Express your updates as deltas rather than destinations. To take the classic example, suppose you have a system that records stock in inventory. Every time there is a sale, you must subtract 1 (or more) from the inventory count.

So say the present quantity on hand is 10. User A creates a sale. Current quantity = 10. User B creates a sale. He also gets current quantity = 10. User A enters that two units are sold. New quantity = 10 - 2 = 8. Save. User B enters one unit sold. New quantity = 10 (the value he loaded) - 1 = 9. Save. Clearly, something went wrong.

Solution: Instead of writing "update inventory set quantity=9 where itemid=12345", write "update inventory set quantity=quantity-1 where itemid=12345". Then let the database queue the updates. This is very different from strategy #1, as the database only has to lock the record long enough to read it, make the update, and write it. It doesn't have to wait while someone stares at the screen.

Of course, this is only useable for changes that can be expressed as a delta. If you are, say, updating the customer's phone number, it's not going to work. (Like, old number is 555-1234. User A says to change it to 555-1235. That's a change of +1. User B says to change it to 555-1243. That's a change of +9. So total change is +10, the customer's new number is 555-1244. :-) ) But in cases like that, "last user to click the enter key wins" is probably the best you can do anyway.

  1. On update, check that relevant fields in the database match your "from" value. For example, say you work for a law firm negotiating contracts for your clients. You have a screen where a user can enter notes about negotiations. User A brings up a contract record. User B brings up the same contract record. User A enters that he just spoke to the other party on the phone and they are agreeable to the proposed terms. User B, who has also been trying to call the other party, enters that they are not responding to phone calls and he suspects they are stonewalling. User A clicks save. Do we want user B's comments to overwrite user A's? Probably not. Instead we display a message indicating that the notes have been changed since he read the record, and allowing him to see the new value before deciding whether to proceed with the save, abort, or enter something different.

[Note: the forum is automatically renumbering my numbered lists. I'm not sure how to override this.]

Upvotes: 10

Bozho
Bozho

Reputation: 597076

Things are simple in the application layer - every request is served by a different thread (or process), so unless you have state in your processing classes (services), everything is safe.

Things get more complicated when you reach the database - i.e. where the state is held. There you need transactions to ensure that everything is ok.

Transactions have a set of properties - ACID, that "guarantee database transactions are processed reliably".

Upvotes: 0

Milhous
Milhous

Reputation: 14643

If you do not have transactions in mysql, you can use the update command to ensure that the data is not corrupted.

UPDATE tableA  SET status=2  WHERE status = 1

If status is one, then only one process well get the result that a record was updated. In the code below, returns -1 if the update was NOT executed (if there were no rows to update).

PreparedStatement query;
query = connection.prepareStatement(s);
int rows = -1;
try
{
    rows = query.executeUpdate();
    query.close();
}
catch (Exception e)
{
   e.printStackTrace();
}
return rows;

Upvotes: 0

Related Questions