由于记录更新频率太高，异步插件无法执行

Question

问题说明：异步插件间歇性失败，因为实体记录的更新速度非常快

详细分析：我们有一个流程，我们经常与访问团队共享/取消共享实体记录。异步插件在创建和更新后执行。 Dynamics CRM 与多个系统集成并在系统中接收更新。我们正面临一个问题，因为这些异步插件因 SQL 错误而失败，

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

在 Dynamics 365 Web 应用程序中，如果用户创建/更新记录，插件将执行并成功。问题是，如果记录正在通过集成系统进行更新，那么此时插件会失败。我们尝试了以下方法来解决问题，

1. 更改了异步插件的执行顺序
2. 优化插件代码

这些没有多大帮助，我们有什么办法可以在插件执行之间设置延迟？或者有什么其他方法可以克服这个障碍？

***微软说更新记录频率太高（2 条记录更新之间相差 0.07 秒）。由于内部SP“p_CascadeRevokeAccess”的执行导致死锁。

Answer 1

Sql 编号 1205 是关键，事务导致一些死锁。

错误 1205：事务（进程 ID）在资源上与另一个进程死锁，并已被选为死锁牺牲品。重新运行事务

我建议你注意几件事：

1. 您已经提到您确实优化了插件代码，请确保您在插件代码中使用的任何 Query 表达式或 fetchxml 查询中都有“No Lock”
2. 如果您在插件中递归更新同一实体记录，请尝试使用创建/更新消息的预操作并在同一同步事务中更新目标属性，而不是太多异步事务
3. 不确定在您的后操作插件中触发了多少步骤，尽管您已正确设置执行顺序，但只能按特定顺序控制同一事务中的流程顺序。但是您无法控制第二个事务的第 1 步的执行顺序在上游系统更新同一实体记录的第一个事务的第 2 步之后运行。

因此，请尝试编写您需要的流程并在每个插件步骤中改组代码以便更好地处理。尽管 CRM 平台负责一些乐观并发技术，但您必须负责您的实施。否则这将成为维护的噩梦，未来可能无法进行增强。

您还提到了使用访问团队共享/取消共享，此问题可能与主体对象访问 (POA) 表更新有关。如果需要，请与 Microsoft 联系并提供高级支持票证。