In our application we are using a parallel gateway with async service tasks, and no user tasks at all. Turns out his is causing optimistic locking exceptions when writing variables to the executionContext.
The solution suggested a few times on this forum is to mark async tasks as exclusive. I can confirm this helps, but it also looks to me this solution also takes away the advantages of using parellel streams. Am I missing something?
Regards,
Pieter Verdoorn
Your analysis is correct. Setting them to exclusive solves the race condition, but in exchange for parallelism. Note that an optimistic locking exception is not a problem, the job will be retried later automatically.
We have it on our roadmap to look into this and optimize this (esp. around variables).
A Question related to Optimistic Locking Exceptions. When updating a variable with the following statement:
runtimeService.setVariable(execution.getProcessInstanceId(), localCounterName, index);
in my parallel task the following exception is thrown:
org.flowable.common.engine.api.FlowableOptimisticLockingException: ProcessInstance[432e8c00-ca5b-11ea-8257-7e5dc7265423] was updated by another transaction concurrently
if i however use:
execution.setVariable(localCounterName, index);
to update the variable no exception is thrown. Is there a functional difference between both calls? Is there a preferred way to update a variable?
No, they both do the same.
Note that the optimistic locking exception happens when both transactions try to commit at the same time. Most likely, both transactions ran just next to each other in the second try. Unless you’ve ran this hundreds of times and it’s consistent?