Strategies to manage multiple clients able to simultaneously edit same data

Question

How can I deal with situations when multiple clients might edit same object at the same time?

For example, I have a web app with admin console, which lets you edit profile data. Several users want to open the same profile and edit it.

If I just let the things go as they do, I`ll get "the last who saves wins" situation and all the other users will lose their changes.

Blocking object for edit on client, when someone enters edit page, seems relatively easy and overall acceptable for simple objects. However, for complex objects, when different users may want to change different parts of object, merging would be much better. I've read a paper on Conflict-free Replicated Data Types and it seems to be pretty complex and does not cover conflict situations.

Are there any other ways to merge objects? Or maybe there are totally different strategies to deal with the situation?

• gnat: what does "CRDT" stand for? You'll likely have to choose which of two options is more appropriate for particular business case: Pessimistic or Optimistic Offline Lock
• Yury Svechinsky: Conflict-free Replicated Data Types. citeseerx.ist.psu.edu/viewdoc/…
• Yury Svechinsky: Optimistic locking looks good. Is there any way to merge master version of data to client version?
• gnat: the way is right there, in your question. Instead of a single coarse lock, just use several finer grained locks for "different parts of object" you mention. Apply optimistic lock to each of these, write the code specific to your application to account for updates in these parts. Given concurrent nature, you may consider using immutable objects to represent these parts, but that would be a different question, in the context of this one it doesn't matter much
• Yury Svechinsky: I think that could work in most cases I've encountered. Thanks!

Answer 1

There is a technique that can be employed to handle this. There are some assumptions first. You (or your team) must to be in control of all software that can update the data. Based upon this, here is what you can do:

1. Do not lock the data upon original download and while the user is editing it. The reason for this is because locks in general are very bad for performance - for example what happens if a user decides to take a break while an exclusive lock is held?

2. When the user tries to save the data, then acquire an exclusive lock and download the data again. Compare the original downloaded data with the data just downloaded. If the data includes a timestamp for the last update, then just compare the timestamps. You might consider adding a last-update timestamp column for this purpose. If the data is the same, which indicates that no intervening updates have taken place, then update the database and release the lock. If the data is not the same, then release the lock and show the updated data and prompt the user to enter his updates again. You can save his original updates in another tab or window to make this easier. Another possibility is to have the software do a merge and highlight any conflicts.

• Yury Svechinsky: That seems to be variation of optimistic locking that @gnat offered in comments above. A good solution. But the most interesting part, merging, is still uncovered. Can you advice some good practices or tools?
• Bob Bryan: For merging, try taking a look at KDiff3. I have used it before and it is not bad. It is open source that runs on multiple platforms. See this link.