Today’s post is courtesy of Ross Talbot, a Development Principal at Sonoma Partners.
In our continuing coverage of new features included in the CRM Online Spring 2015 Update, today we will be talking about optimistic concurrency.
First, a little review of data quality and minimizing data loss. Just as in life, there are two basic models for minimizing loss when updating data in your database: optimistic concurrency and pessimistic concurrency. Pessimistic concurrency uses row locks to prevent others from making changes while you are performing an update. This prevents a conflict by calling “dibs” and then releasing the lock when you are done. Optimistic concurrency involves an attempt to update and then a rollback if there is a conflict. This prevents a conflict by stopping the second update and letting the user know via an error message. Optimistic data tries first before stopping, and pessimistic data fights others off until its update is complete.
What does this mean for Dynamics CRM today? The lifeblood of your business starts with your customers, so from a CRM system perspective your customer data is vital. With integrations, mobile applications, and multiple users accessing and updating this data, you want to be sure that a situation that could potentially result in data loss is handled in a way that minimizes that potential issue. So let’s dive into an example of how these updates can be used in your code.
Before we start, optimistic concurrency is supported with this update on all out of the box entities enabled for offline sync as well as all custom entities. This is found as a metadata setting “IsOptimisticConcurrencyEnabled” and is set to true if the entity supports it. I have also set up a console app with some basic logging and an organization service to create a contact and test optimistic concurrency via an update and a delete.
Inside the app, I create Bob Brightside and then retrieve the record again so I can obtain the Row Version needed to check during our Update attempt.
From our log file, I see that Bob was created and that the current Row Version is 459773:
INFO "Contact Bob Brightside created with id: 24496e99-470a-e511-80d9-c4346bac7dac"
INFO "Row Version before update attempt: 459773"
Next, I use a breakpoint in my console app to simulate the timing of two updates. One will be made in my console app and the other in the browser. In my code, I will change the First Name field on the contact to Robert. I use the new ConcurrencyBehavior property to check the row version on my update. If the Row Version in CRM matches the Row Version of the contact record I am updating, the update will succeed. If these versions do not match, or if no Row Version is specified, the update will fail. I pause at the breakpoint in order to update the contact via the CRM web interface, changing the First Name field to Mr. replacing Bob.
When I resume my console app, the update request is executed and the update fails.
From our log file, we see that the concurrency check noticed another change had occurred and prevented our update:
ERROR "Concurrency Check Failed: The version of the existing record doesn't match the RowVersion property provided."
Next, I retrieve the record again to ensure I have the latest Row Version. Our log shows this has been updated: INFO "Row Version after update attempt: 459780"
I now execute a Delete Request with the updated contact and the ConcurrencyBehavior property set to IfRowVersionMatches, and since no other updates have been made this request succeeds.
Here is a link to the MSDN article detailing this new feature for more information about the supported entities, fault codes when concurrency checks throw an exception, and additional sample code.
Are you having any issues with your CRM deployment? Concerned that you aren’t doing enough to prevent data loss? Don’t grumble, give a whistle. We can help things turn out for the best.
