FAQ: What Happens When Two People Edit the Same Object at the Same Time?

re: FAQ: What Happens When Two People Edit the Same Object at the Same Time?

Brent — Thu, 10 Mar 2011 14:24:44 GMT

Travis, in follow up to AndersAsp's example, we are currently running into that scenario very freqently. I wanted to see if you had any information of anything that might be in the pipeline to address this major problem? Perhaps in R2? Even if the apply button locked the CR with a green in-progress bar while the workflows ran, that would be an improvement as it would prevent users from making changes until the workflows were done. Or, other option, if the CR Status field didn't lock the entire CR. Thx Travis!

re: FAQ: What Happens When Two People Edit the Same Object at the Same Time?

Mohamed Garrana — Sat, 02 Oct 2010 20:49:16 GMT

good engineering , not magic

re: FAQ: What Happens When Two People Edit the Same Object at the Same Time?

Travis Wright MSFT — Mon, 27 Sep 2010 13:33:07 GMT

@AndersAsp - That's a great scenario. We'll do some thinking about how we could improve that. Thanks!

re: FAQ: What Happens When Two People Edit the Same Object at the Same Time?

AndersAsp — Mon, 27 Sep 2010 06:33:21 GMT

@Travis

These kind of errors do appear in practise. They do occur very rarly in Problem and Incident, but quite frequently in Change. The reason for that is the 'Change Request Status Changed' workflow that runs in the background for the CRs. One example of this would be when our analysts enters some of the information in the CR form, then hit apply. Then, without refreshing or re-opening the form, they will enter more information and then tries to save it again. Which wont work ofcourse, since the workflow has changed the status from 'New' to 'In Progress'.

There is an easy answer to the example above: "Don't hit apply"! Unfortunately, it aint easy to get our 50 analysts to understand that...

However, I do like all of your suggestions to fix or warn for this Travis!

re: FAQ: What Happens When Two People Edit the Same Object at the Same Time?

Travis Wright MSFT — Sat, 25 Sep 2010 03:03:17 GMT

@GaryJ - There are a few problems with the "Word" approach:

1) It assumes that everyone that opens an object to view it also wants to edit it. In many cases a user may just want to look at the current state of the object and is fine with other users editing the object in the background. You would actually have many more "collisions" this way and it likely would result in a different (and possibly more severe) type of user frustration because Bob might open an incident and go out to lunch. Meanwhile Tom can't update the incident! SLAs could be missed because the object is locked like this. You could develop a two-state system where the first user can choose to open the incident in view mode or edit mode (like Office 2010) but this puts additional cognitive load on the user, takes longer to develop/test, and it can still often result in objects being completely locked.

2) It would lock out automatic updates from connectors and workflows which could break the automated portions of the process or prevent the most up to date information from being available to the user to make decisions from.

3) It's actually more difficult to implement the "Word" approach, especially if you wanted to do the edit/view approach, notify users when the object is available for editing, etc. FWIW - the current implementation is actually very simple in terms of coding which means that it is very efficient and not as prone to bugs and such. Basically all that is happening behind the scenes is that the database returns a datetime property of the current time with the object when the object is requested by the console. When the object comes back to the database on an update the database does a check to see if the datetime property is older or newer than the last modified time.

I do agree with you that there are optimizations that we could make to the current design though and hopefully we'll get to those soon enough. Here are some examples:

1) Allow non-conflicting property level updates (as described in the blog post).

2) Notify a user on open if another user has recently opened an object.

3) Notify a user while editing that another user has updated. This could prevent the user entering further information that will be lost.

Each of these improvements has tradeoffs though. We could spend time developing/testing those instead of developing other features. There could also be performance implications to them and the user experience could become more complicated.

It will be interesting to see how many conflicts there are in practice with the current design. So far I haven't heard any complaints about the current design, but if there are feel free to let us know!

re: FAQ: What Happens When Two People Edit the Same Object at the Same Time?

GaryJ — Fri, 24 Sep 2010 21:10:05 GMT

This all seems rather crazy and unhelpful to me since there are so many circumstances where one user is likely to receive an error and maybe lose a large edit. Not only can this be frustrating but it may be a negative experience for a customer. Rather than code what must be a complex optimistic mechanism why not implement the tried and trusted Word method where the first one wins and second can open in read only mode? This seems a far more sensible approach to me.