并行服务任务遭遇OptimisticLockingException问题及优化需求求助

核心问题分析 #

你遇到的问题根源有两个：

1. Service Task重复触发：开启async before=true后，Job Executor可能因锁超时、重复拾取Job等原因，导致同一个Service Task对应的Job被多次执行；
2. OptimisticLockingException：并行子流程属于同一主流程实例时，多个并行节点同时更新流程数据，触发乐观锁冲突。

用exclusive=true会强制同一流程实例的所有排他Job串行执行，虽然解决了重复触发，但牺牲了子流程的并行性，不是最优解。

针对性解决方案 #

1. 控制Job唯一性，避免重复触发 #

• 调整Job Executor锁配置：确保Job被拾取后，锁的持有时间足够覆盖Service Task的API调用时长。比如在流程引擎配置中设置：

  processEngineConfiguration.setJobLockTimeInMillis(60000); // 设置锁时长为60秒，根据API调用耗时调整
  

  这样可以防止Job被其他线程重复拾取执行。
• 检查流程定义的触发逻辑：确保Service Task没有被错误配置为多实例触发，或者没有重复的序列流指向该节点。

2. 业务层面实现幂等控制 #

在Service Task执行前，通过流程变量标记任务是否已完成，避免重复调用API：

• 在Service Task的执行逻辑开头，先检查自定义变量（如api_called_${subprocess_id}）：

  String flagKey = "api_called_" + execution.getVariable("subprocessId");
  if (Boolean.TRUE.equals(execution.getVariable(flagKey))) {
      return; // 已执行过，直接跳过
  }
  // 调用API逻辑
  // ...
  // 执行完成后设置标记变量
  execution.setVariable(flagKey, true);
  

  这种方式即使Job被重复触发，也不会重复调用API，同时不影响子流程并行。

3. 让子流程成为独立实例，实现并行+串行控制 #

如果你的子流程是通过Call Activity调用的，可配置子流程为独立实例：

• 在Call Activity的属性中开启independent（独立实例），这样每个子流程会生成单独的流程实例ID；
• 给子流程内的Service Task设置exclusive=true，此时exclusive只会作用于当前子流程实例的Job，不同子流程实例的Job可以并行执行，既保证了单个子流程内的Service Task不重复触发，又实现了子流程之间的并行。

4. 处理OptimisticLockingException #

• 开启乐观锁重试：在流程引擎配置中添加重试拦截器，当遇到乐观锁异常时自动重试：

  processEngineConfiguration.setRetryInterceptor(new CommandRetryInterceptor(3)); // 设置重试3次
  

• 避免并行节点更新同一变量：如果并行子流程需要更新共享变量，改用异步更新或者通过信号、事件等方式串行处理变量更新，减少锁冲突。

总结 #

优先尝试业务幂等控制+Job锁配置调整，如果子流程适合独立实例化，用独立子流程+exclusive=true的方案更彻底。这些方案既能保证子流程并行运行，又能避免Service Task重复触发和乐观锁异常。

内容的提问来源于stack exchange，提问作者nilofar