Hello there, I need a bit of you help regarding concurrency
We get “ENGINE-03005 Execution of ‘UPDATE ExecutionEntity[f6a6b492-9e4b-11ee-aa75-0a58645e0bc9]’ failed. Entity was updated by another transaction concurrently”. This id is an id of a process instance.
In this particular flow we use mostly external delegates with parallel gateways, with 3 replicas of a worker. We also use fetchAndLock(). Upon reducing the number of replicas to 1, everything’s fine (obviously). Now, I suspect the issue is that some time ago we’ve reduced the default number of retries to 1, because we’ve identified some of our delegates are not atomic and this seemed like an easy fix. Apparently it prevents the engine from managing optimisticLockingExceptions like it would normally do.
At the same time I would expect a possibility of keeping retries at 1 and job executor being able to handle these exceptions by itself. I have read somewhere that it’s possible without savepoints/asynchronous continuations, but I am afraid that’s only possible for delegate expressions and not external workers. Currently I have asyncBefore and exclusive checked at each external delegate.
Let me add that I made sure workers have unique IDs.
I would greatly appreciate any suggestions, as there are many “constraints” that start to mix up. Cheers!
An external task is automatically considered a “savepoint”, which saves the state of the process, that is, it is the only type of service task considered a transaction point.
The first thing we need to check in your BPM flow is whether there is a messaging service triggering messages for different message events (generally non-interrupting) that may be updating the same variable in the process.
@radzyor can you please mark your join parallel gateway as async before and see if you get any improvement? This way it will be harder to get an optimisticlock on the scenario where 2 paths comes to an end on the same gateway at near the same time, as it will let a single new job to continue from the gateway, in a new job executor thread instead of reusing the older tasks threads.
