We get asked this one a lot: What happens when two people edit the same object (like an incident record for example) at the same time?
It’s inevitable in a distributed application with many people that each have their own interface that you will have two people try to update the same thing at roughly the same time. So – how do we deal with this in SCSM?
Let’s take the most common scenario and the one that people seem the most concerned with – incident management…
Here’s a scenario for us to work with in this timeline:
What happens to Bob here? The answer is that it depends on what update Bob is trying to make. We try to be “optimistic” (geeky developer term) in allowing updates to happen. For example, let’s say that Tom changes the incident urgency from High to Medium. Bob is trying to change it from High to Low. We don’t want to let Bob change it from High to Low without knowing that Tom has changed it to Medium. So in that scenario we reject Bob’s attempt to update an incident and show him an error message that looks like this:
He has to close the incident form and reopen it to get the latest data. That way he is acting in an informed way with the most up to date information.
So – that scenario was obvious since they were both trying to change the same property value. Ideally, we would
“optimistically” allow different property values to be submitted. For example, let’s say that the only thing that Bob changed was the title of the incident and the only thing that Tom changed was the urgency. Since those don’t really conflict with each other we could allow them both to be able to update the incident. We’ll that’s an ideal world! :) The reality is that if anything has changed on the object itself the later update is rejected. So – in this case Bob would be rejected again. Poor Bob! :)
Here’s another case – Bob changes the Urgency from High to Medium and the Title from ‘Foo’ to ‘Bar’. Tom changes the Urgency from High to Medium. Even though Bob and Tom agreed on the Urgency, because Bob updates last and some property on the incident object itself has been updated, Bob’s update will be rejected. Again. Ouch!
There is one case where we do allow “optimistic” updates – relationships! Keep in mind that an “incident” is really comprised of an incident object and it’s relationships to other objects. The incident object has properties like Title, Urgency, Impact, Priority, Created Time, etc. It also has relationships to other objects like the Affected User relationship which relates an incident to a user. The affected user is not a property of the incident object even though it kinds of seems that way on the form because it looks like any other control on the form.
Let’s say Bob adds a computer named ‘bobscomputer’ to the affected configuration item list of the incident. Let’s say Tom adds a computer name ‘tomscomputer’ to the affected CI list. In this case, Bob’s update will be allowed! This is true of relationships with cardinality greater than 1 (affected CIs for example) or for cardinality equals 1 (affected user, assigned to user, etc.) relationships.
So – how does this all work? Let’s say that the last modified time of the incident in this scenario prior to Bob or Tom doing anything is 8:00. When Bob opens the incident record he gets a timestamp (8:01). Tom also gets a timestamp (8:03) when he opens the form. When Tom updates the incident at 8:08 his timestamp (8:03) is greater than the last modified time (8:00) and therefore his update is allowed. The last modified time on the incident is updated to 8:08. When Bob tries to submit his incident his timestamp (8:01) is less than the current last modified time (8:08) and therefore his update is rejected.
This is also true for system updates from a connector or a workflow. In the scenario below Bob’s update will be rejected.
Hope that helps explain how we handle two users editing the same object at the same time!