Concurrency problem on *separate* process instances

Hello,

I have been reading around this forum about concurrency and optimistic locking issues when multithreading on the same process instance, but I seem to have this problem when multithreading on different instances.

So basically I have two different instances of the same process definition, and two different users who trigger the finalization of their respective process instance more or less simultaneously. This one particular time, user #2 recevied the following error message: ENGINE-03005 Execution of 'UPDATE ExecutionEntity[xxxxxxxxx]' failed. Entity was updated by another transaction concurrently. which is totally weird, because after some digging in the Camunda database, I found out that the referenced id belonged to the process instance of user #1 (the other one).

So this begs the question - why does finishing an execution for user #2 suddenly complain about the execution of user #1, even though they are two different process instances?

I’m not asking for help with my software*, I just want to know if this is theoretically possible in Camunda or maybe even exptected behavior. *This error appears to have caused transaction rollbacks in a distributed-transaction environment, so I have to rewrite the mechanism in my application anyway.

Just for info, the error occurred with Camunda 7.6 on JBoss EAP 7.0. I couldn’t reproduce it with either C 7.6 / JB 7.0 or C 7.10 / JB 7.1 or C 7.10 / JB 7.2, so my theory at the moment is, that it must have been some timing / locking problem.

Therefore, again, my question is - is it possible that two different instances can cause a concurrency problem, or do I have to keep looking in my own applicaiton?

Thanks a bunch!
Cheers, Raoul

Hello @Angry_Scientist,
Even if it is a quite late reply I’d like to take the chance and answer as we have a similar problem description in another case.
The workflow engine executes in its default configuration one process instance always single threaded. That assures that all database transactions also run in only one thread. It does not necessarily mean that always only one thread has access to that process instance, e.g. two parallel user tasks are completed the same time or a variable is set via REST API while another job is currently being executed. Those cases usually lead to an Optimistic LockingException but should normally occur only very rare.
The problem you describe can by design of the engine not happen. Two threads working on different process instances will not attempt to update another instance. If that really happens it has to be considered a bug.
I would like to have a closer look to your actual process model and its configuration, if that error still occurs from time to time.

Best, McAlm

Hi @McAlm!
Thank you for your reply! In the mean time we have rewritten our code to improve concurrency and also upgraded the Camunda engine a few times and we no longer have this problem.
Cheers, Raoul