Design Strategies – Managing Multiple Clients Editing Same Data Simultaneously

Architecturedesignprogramming practices

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?

Best Answer

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:

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

Related Solutions

Polymorphism – Is Down-Casting Always Bad?

Downcasting a pointer vs making a generic payload into a specific object are two different things.

The common messaging system API should have a set of functions for returning the exact object you want so that you aren't constantly downcast in your application code (which is more error-prone).

You're basically talking about passing around objects using XML or JSON or some other data interchange format. Talking about downcasting is unnecessary because it should already be handled by the common messaging system API since you know exactly what sorts of objects are being passed around.

I'm assuming the system API looks like this:

GeneralObject* getObject(Message *message);

It should look like this:

GeneralObject* _getObject(Message *message); // the _ is just to indicate this is a private function that shouldn't be used outside of this module

// these raise exceptions if the object doesn't exist or return null or whatever
Person* getPerson(Message *message);
Place* getPlace(Message *message);

Never in your code will you use the generic function that returns the base class, you'll always use the code that returns the derived classes and let the API handle or raise errors if it can't downcast.

Downcasting in this case is basically failing to parse or de-serialize an object.

Google's protobuf library has an example of what I'm talking about

Returning HashMap of String to Object – Should It Be Avoided?

The decision depends on many things:

Is the caller method aware(at code-time) of the map's structure?
When I say "code-time" I mean that when you write the code you have a specific structure in mind(compared to compile-time and runtime). If you don't, and the method should be able to handle any structure you throw at it(for example - a method for converting that map to JSON format), then you don't really need to document that structure outside the method that creates the map, since it doesn't need to be refered by a human outside the scope of that method.
Are you using a static or a dynamic typed language?
Dynamic languages tend to depend less on well defined data structures. In JavaScript, for example, there is no difference between an object and a map, and Ruby has OpenStruct that creates objects that are both structs and maps. When you don't have a strong type system you should be less strict about writing self-documenting code at the API level.
Does the language you use provide a better way to do what you want?
For example, many static typed languages have enum types, and you can often use those enum types as the keys of a map instead of string. This will allow you to have the self documenting code you want(the enum type declaration is a list of all keys used in that map) while still being able to iterate over all the key-value pairs without using reflection.

If you provide more details we might be able to provide more help.

Best Answer

Related Solutions

Polymorphism – Is Down-Casting Always Bad?

Returning HashMap of String to Object – Should It Be Avoided?

Related Topic