java - Camunda 服务任务的 OptimisticLockingException

Question

我们在具有以下场景的 Camunda 进程中看到 OptimisticLockingExceptions:

该进程由一个 UserTask、一个 Gateway 和一个 ServiceTask 组成。 UserTask 执行

runtimeService.setVariable(execId, "object", out);`. 
taskService.complete(taskId);

以下 ServiceTask 使用“object”作为输入变量(不修改它)，并且在完成时抛出 OptimisticLockingException .我的问题似乎源于这样一个事实，即 taskService.complete()在刷新 UserTask 中设置的变量之前立即执行 ServiceTask。

我有另一个相关的问题，当我在一个 UserTask 中执行 runtimeService.setVariable(Map<Strong, Boolean>) 时发生。并尝试在该 UserTask 之后的网关中作为转换守卫访问 Map 的成员。

我找到了以下文章:http://forums.activiti.org/content/urgenterror-updated-another-transaction-concurrently这似乎与我的问题有关。但是，我不清楚这是否是(不)想要的行为以及我如何访问 DelegateExecution 的问题。 - 来自 UserTask 的对象。

Answer 1

我们认为经过漫长而繁琐的搜索，我们已经确定了 camunda 的两个问题(加在一起)导致了原始问题的异常。

1. Camunda 使用 equals在序列化对象(由字节数组表示)上确定是否必须将流程变量写回数据库。这甚至发生在仅读取而不设置变量的情况下。作为equals由数组上的指针标识定义，如果一个可序列化的对象被多次序列化，则它永远不会被确定为“相等”。我们发现，单个 runtimeService.setVariable()在 completeTask() 时导致四个数据库更新(一个用于 setVariable 本身，另外三个用于各种 camunda 内部验证操作)。我们认为这是一个错误，并将向 camunda 提交错误报告。

2. 显然有两种设置变量的方法。一种方法是使用 runtimeService.setVariable() ，另一种是使用delegateTask/delegateExecution.setVariable() .同时使用两种方式时存在一些缺陷。虽然我们不能将我们的设置简化为简单的单元测试，但我们已经确定了发生异常所必须涉及的几个组件:

2.1 我们正在使用 TaskListener在这个任务监听器使用的任务开始时设置一些上下文变量 runtimeService.setVariable()而不是 delegateTask.setVariable() .在我们改变它之后，异常消失了。

2.2 我们使用(并且仍在使用)runtimeService.setVariable()在任务执行期间。我们切换到completeTask(Variables)之后并省略了 runtimeService.setVariable()电话，异常也消失了。但是，这不是永久性的解决方案，因为我们必须在任务执行期间存储流程变量。

2.3 异常仅在过程变量由 delegate<X>.getVariable() 读取或写入时组合出现方式(通过我们的代码或隐含在使用网关和 serviceTasks 或 completeTask(HashMap) 进行 juel 解析的 camunda 实现中)

非常感谢您的所有意见。