Multiusers systems and CRUD

Question

I am redesigning a large enterprise web system and a major concern has come across the table. The system allows for many users to Create, Read, Update, and Delete items in the system. This is problem if two or more users are editing the same file or item.

What is a good technology or approach to integrate on this? Several things must be considered, for example:

• User may not delete an item if another user is updating it
• An item in editing, should be eventually released so that the user is not holding on to it forever and prevent someone else from editing it
• Make new items/new changes available even while on editing mode (for example, in Stack Exchange, if someone posts an answer to this question while I am writing my own, a dialog appears that says an answer has been posted to this question. I am not able to see it, but as soon as I finish my edit, I can see the answer without refreshing the screen)

If your suggestion comes with more features out of the box or you have any added suggestions or caveats, I am open to them.

Thanks

Answer 1

There are generally four options to handle collaborative data maintenance in a multi-user system:

1. Just overwrite it. Mindlessly process requests in the order they arrive at the server. When user B tries to update an item which user A just deleted, just give an error message "this item doesn't exist". When user A and user B update the same item just milliseconds apart, you take the last one. Simple, crude and prone to mistakes, but can be appropriate in some situations.
2. Locking and unlocking. Before a user can update a record, they first need to lock it. Only one user at a time can have a dataset locked. When someone else tries to lock it, they get an error message "User XYZ is currently editing this item". When they save the data (or abort the edit), the dataset is unlocked.
3. Versioning and conflict resolution. Whenever a user saves an item, a new version is created. When someone else created a conflicting version in the meantime, any differences are shown to the user and they can decide how to resolve the conflicts.
4. Real-time collaborative editing. Users get notified when another user is editing the same item. They can see each other's cursors and selections. Changes appear on each other's screens in real-time. (e.g. Etherpad)

Which solution is the best depends on your business needs. The most important aspect is usually how long your users will take to update a record. When it's a matter of seconds, you would prefer the first option. When it's a matter of minutes, you would prefer the second option. When an update can take an hour or longer, you would prefer the third option.

The fourth option can be really neat for some kinds of highly collaborative work, especially in an environment where users can't communicate directly. But it isn't always appropriate. It can also be very difficult to implement in a user-friendly manner. You might also want to add a meta communication-channel, so users don't need to communicate by writing into the data itself ("Description: This item is a PETER GO AWAY I WAS HERE FIRST!!").

Answer 2

In addition to Philipp's answer is one more that I use in quite a few systems which is notficaion and override.

It's kind of like #1 and #2 combined.

Say you have a text body, you md5 (or CRC, or something else cheap, I user updated_at) your record. Then send that with the record. Then as the record comes back if that "hash" doesn't match then another "override" parameter needs to be included.

So for example, you have a document, it has body, and hash.

When you post the document,

• if the hash matches (no changes) then just blind write.
• if the hash does not match (changes) then throw an error (that the document form can work from)
• if the hash does not match AND the override param is present, blind write.

Works well when you have a change that could take a wile, so you don't want to just blind write, but when most of the time that is exactly what happens anyway.

Also works well in JSON or other transports. Can be contained entirely in the data layer (You UI layer needs to display the error, of course, but the check and override is in data), and is backwards compatible with clients/front ends that don't support the override (they just get an error), and works VERY well when users are fighting automation (imports, for example.)