Asynchronous Plugins failed to execute as Record update frequency is too high

1
votes

Problem Statement: Asynchronous Plugins are failing intermittently because entity Records are being updated at very high pace

In Detail Analysis: We have a process where we frequently share/un-share Entity Records with Access Team. Asynchronous plugins executes after create and update. Dynamics CRM is integrated with multiple systems and receives updates in the system. We are facing an issue as these Async Plugins are failing with SQL Error,

Sql error: Generic SQL error. CRM ErrorCode: -2147204784 Sql ErrorCode: -2146232060 Sql Number: 1205

In the Dynamics 365 web application, if user creates/updates a record, plugin executes and succeeded. Issue is if a record is being updated through integrated systems, at that point of time plugins fails. We tried below things as to resolve the issue,

  1. Changed the order of execution of Async Plugins
  2. Optimized the plugin code

These are not helping much, is there any way we can put delays between Plugin executions? Or any other way we can overcome this hurdle?

***Microsoft says update record frequency is too high(0.07 sec difference between 2 record update). Deadlock is being caused due to the execution of internal SP "p_CascadeRevokeAccess".

1
dynamics-crmmicrosoft-dynamicsdynamics-crm-onlinedynamics-crm-365
I faced this same issue in my UAT today, we are changing the Post-Create plugin as Synchronous. The error is gone :) Though no issue in Prod with Async plugin - Arun Vinoth - MVP

1 Answers

1
votes

Sql number 1205 is the key, transaction causing some deadlocks.

Error 1205 : Transaction (Process ID) was deadlocked on resources with another process and has been chosen as the deadlock victim. Rerun the transaction

I would recommend you to take care of few things:

  1. You already mentioned that you did optimize the plugin code, make sure you have "No Lock" in any Query expression or fetchxml query that you are using in plugin code
  2. If you are recursively updating the same entity record in plugin, try using pre-operation of create/update message and update the target attributes in same synchronous transaction instead of too many asynchronous transactions
  3. Not sure how many steps getting triggered in your post-operation plugin, though you have execution order set properly, only the order of flow within the same transaction can be controlled in specific order. But you cannot control the execution order of step 1 of second transaction to run after the step 2 of first transaction of the same entity record update by your upstream systems.

So try to compose your needed flow and do shuffling the code in each plugin step for better handling. Though the CRM platform take care of some optimistic concurrency techniques, you have to take care of your implementation. Otherwise this will become a maintenance nightmare and future enhancements may be impossible.

Also you mentioned about sharing/unsharing using access teams, there is a possibility that this issue could be related to Principal Object Access (POA) table updates. Check with Microsoft with a premier support ticket if needed.