Camunda：如何在我的工作流程中找到引发 OptimisticLockingException 的步骤答案

【问题标题】：Camunda : How to locate the step in my workflow that provoke OptimisticLockingExceptionCamunda：如何在我的工作流程中找到引发 OptimisticLockingException 的步骤
【发布时间】：2021-01-21 21:05:59
【问题描述】：

在繁重的负载下，我们的一些进程遇到了很多 OptimisticLockingException 异常和作业重试（这会导致很多麻烦）。

当没有负载时，编排器不会抛出任何 OptimisticLockingException 异常

您能否建议一种方法来定位哪些步骤会引发这些并发操作？

170556:2021/01/21 21:35:04.022 DEBUG ENGINE-16002 Exception while closing command context: ENGINE-03005 Execution of 'UPDATE ExecutionEntity[223d44fe-5c28-11eb-aa7e-eeeccf665d52]' failed. Entity was updated by another transaction concurrently. {"org.camunda.bpm.engine.OptimisticLockingException: ENGINE-03005 Execution of 'UPDATE ExecutionEntity[223d44fe-5c28-11eb-aa7e-eeeccf665d52]' failed. Entity was updated by another transaction concurrently.":null}

170986:2021/01/21 21:35:04.107 WARN ENGINE-14006 Exception while executing job 23e3a29c-5c28-11eb-80a2-eeeccf665d52:  {"org.camunda.bpm.engine.OptimisticLockingException: ENGINE-03005 Execution of 'UPDATE ExecutionEntity[223d44fe-5c28-11eb-aa7e-eeeccf665d52]' failed. Entity was updated by another transaction concurrently.":null}

107264:2021/01/21 21:35:36.407 DEBUG ENGINE-16002 Exception while closing command context: ENGINE-03005 Execution of 'DELETE TimerEntity[f723f288-5c27-11eb-aa7e-eeeccf665d52]' failed. Entity was updated by another transaction concurrently. {"org.camunda.bpm.engine.OptimisticLockingException: ENGINE-03005 Execution of 'DELETE TimerEntity[f723f288-5c27-11eb-aa7e-eeeccf665d52]' failed. Entity was updated by another transaction concurrently.":null}

如果您可以建议一种避免重试异步任务的方法，那就太好了，正如这个问题中所问的那样 https://forum.camunda.org/t/how-to-avoid-retry-of-async-service-tasks-when-an-optimisticlockingexception-occurs/21301

环境： 2 个 Spring Boot Camunda Orchestrator 实例

<camunda-bpm.version>3.4.0</camunda-bpm.version>
<camunda-engine.version>7.12.0</camunda-engine.version>

带有 read_commited 的 Postgres 9.12

【问题讨论】：

标签： camunda camunda-modeler

【解决方案1】：

OptimisticLockingExceptions 是一种保护您免受更新丢失的机制，否则可能会导致对相同执行数据的并发访问。一个事务首先更新了父执行（V1>V2）。流程引擎然后让第二个事务重做它的操作（在 V1 上，同时陈旧），但这一次基于最新版本的执行 (V2)。然后第二个事务创建新版本的执行（V2>V3）

所以 OLE 可以发生在并发发生的地方。您使用的是并行网关还是包容网关？事件是否触发并发令牌流？

了解流程模型/引擎中何时发生并发并评估是否确实需要并发执行。在许多情况下，人们会建模，例如两个服务调用并行，每个只需要几毫秒。那么总处理时间并没有增加（创建和合并并发作业也需要时间），但并发可能会成为一种负担。所以尽可能选择顺序执行。

检查您的交易持续时间。如果您有更长的事务组合多个服务调用，则将它们拆分为多个作业会很有帮助（这取决于用例。更多的作业也意味着更多的作业）。

处理 OLE 时最重要的最佳实践是在合并并行网关之前检查异步。这不会完全阻止 OLE，但作业执行器的内置重试机制会为您处理它们。

最后但并非最不重要的一点是，当系统负载高且数据库性能不佳时，OLE 会越来越多地发生。调整整体系统性能以减少 DB 负载和 OLE。

【讨论】：