Question

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

Variation 1

• user sends request
• server reads data
• server modifies data
• server saves modified data

Variation 2:

• user sends request
• server reads data
• server sends data to user
• user sends request with modifications
• server saves modified data

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:

• web application, but language unspecified
• potentially, using a web framework
• data store is a SQL relational database
• the logic involved is too complex to express well in a query e.g. value = value + 1

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.

Answer 1

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.]