Issue of two people/process editing the same object at the same time and later person/process not able to update object is a known issue in Service Manager. This gives very bad experience to a user who is trying to submit changes through Console. When this issue occurs, the only option the user has is to close the form and reopen it to get the latest values. The user loses all input values they provided before submitting and have to input all values again in the reopened form. For more details on issue refer this link - http://blogs.technet.com/b/servicemanager/archive/2010/09/24/faq-what-happens-when-two-people-e... . Concurrency is currently the #1 request in Service Center Public Feedback ( https://connect.microsoft.com/WindowsServer/Feedback/Details/1062768 ). SM Team understands the pain our customers are going through and to alleviate this pain, the fix for the issue is now on its way in UR7. This blog talks about how this fix works.
Issue
SM currently supports Optimistic Concurrency based on “Last Modified Date” in the following manner -
- When a Work Item (WI) is read or created (saved first time) on Console, the “Last Modified Date” is fetched for the WI from CMDB.
- When a user tries to update WI through Console, same LastModifiedDate is passed along with changes to SDK.
-
SDK while updating in CMDB checks whether the LastModifiedDate matches to the one in CMDB for that WI -
- If it matches, save is successful.
- If it’s not matching, SDK throws back DiscoveryDataModificationCollisionException and user sees the below exception message on Console –
This exception is a common scenario for users while creating new Work Item (WI). It is also experienced during Change Request (CR)/Service Request (SR), when a user creates a new CR/SR through form on Console and saves it by pressing ‘Apply’ button. When they make some more update to WI in the same form and submit (press OK/Apply button) again, they get this exception message. Primary reason of this exception is workflows (WF), which change status of these Work items in background. Like here in case of new CR/SR, this happens as WF runs within some 30 secs of creating new CR/SR to change its status from ‘New’ to ‘Inprogress’ in background and when user tries to submit more changes after this status change, they get the above error.
Merge Concurrent Changes
This exception is observed in Console by end user but the actual exception is raised in SDK, while updating the records in CMDB. In order to fix this issue at root level, we have added merge support in SDK rather than in Console. Another benefit of this approach is that for all apps which directly use SDK to update any entity i.e. console, powershell, WFs and third party applications, fix works seamlessly. We have added the logic for retrying rather than failing bluntly. Post UR7, SDK update submission logic is to first submit changes in normal way, but when exception is raised it merge s changes with current values and retries submission to CMDB. Merge will work only in case when changed properties fall under either of these buckets -
- Current values in CMDB matches original values that form read, irrespective of changed values that user is submitting.
- Changed value matches with Current Value in CMDB, irrespective of original value form read.
Here is an example of when SDK will do insertion after merge (which would have failed with current SM Optimistic Concurrency Model) –
|
Sample Properties |
Values read when Form Opened |
Current Values in CMDB |
Changes user trying to submit |
|
Title |
X |
A |
A |
|
Description |
Y |
Y |
C |
|
Priority |
Z |
B |
|
|
Assigned To |
(null) |
(null) |
D |
Although this merge algorithm will work in most of the reported cases (including CR/SR where Workflows in background changes status), it will fail when two users/processes try to modify same property concurrently. Here is one example where changes are not disjoint sets and due to this we won’t allow insertion
|
Sample Properties |
Values read when Form Opened |
Current Values in CMDB |
Changes user trying to submit |
|
Title |
X |
A |
A |
|
Description |
Y |
Y |
|
|
Priority |
Z |
B |
C |
|
Assigned To |
(null) |
D |
Change in User Experience
Changes in console have also been added such that form is auto refreshed to reflect latest changes of non-conflicting fields (presumably done by other WFs or users) . A notification is provided to the user as well, informing of the changes that resulted after the submit thus ensuring the user always has the latest updates in the form. For these console features, patch(UR7) needs to be installed on machines where Console is installed -
1. Auto-Refresh of form after Save – This will get latest value from CMDB into form.
2. In case if merge is not possible due to same property is changed by some other user/process (like in second table above), user will be informed on conflicting properties in exception message with latest value from CMDB as shown in following snapshot.
This will allow user to decide to not to continue with doing changes (like cases where status changed) or change conflicting properties to current value from CMDB and resubmit form without reloading form (and loosing other values user has inputted)
3. In case if any properties have changed in background, warning will be shown to user about some property got reloaded after save–
This improvement will help us in fixing most common end user scenarios –updating a working item which was modified by Workflow(s) in background and two users have modified different properties. This fix is targeted to be released in Update Rollup 7 (UR7). However if you want to get your hands dirty with this fix before then, you can get it right now as part of the TAP Drop. For more details on TAP and how to join, please see the following: Become a Member of the System Center Service Manager Agile TAP!