Optimistic Locking Exceptions in Process Execution with Timer Boundary Events

Hello everyone,

I’m encountering an intermittent issue with process execution related to optimistic locking exceptions. Specifically, the problem occurs with a task that runs immediately after a receive task with a timer boundary event attached. This issue is intermittent and affects only a few process instances, causing the job to retry. On the second attempt, the job succeeds without errors.

Upon investigation, we found concurrent updates to the ACT_RU_VARIABLE table, which might be related. We’re seeing the following exceptions:

  • ENGINE-16002 Exception while closing command context: ENGINE-03005 Execution of 'UPDATE VariableInstanceEntity[19281363-67d0-11ef-9063-fa0d143efe8e]' failed. Entity was updated by another transaction concurrently.
  • ENGINE-14006 Exception while executing job 27f28bce-67d0-11ef-ab45-b2bfae04a76d: OptimisticLockingException

The optimistic locking exception appears right after the above exception.

I suspect this might be due to some modeling issues. Can anyone offer insights or suggestions on how to address this?

BundlePurchase.bpmn (24.5 KB)

Hello my friend!

Yes, a more appropriate modeling will probably solve your problem with OptimisticLocking.

This concurrency error in Camunda can happen in several situations, which we must be careful about when modeling our processes…

A case that I saw in your modeling, and that may be generating this error, is that you have a total of 3 message events… one of which is a start event… this may cause conflicts if they are triggered simultaneously… and perhaps if you receive a message event at the same time as your timer is triggered…

Another thing that could conflict, but to be sure you can only see the code… is that if you update the same variables at the same time in 2 different places, there will be a conflict… for example, if when triggering the start message event you update a variable called “statusProcess” with the value “PROCESS_STARTED”… and at the same time you updated the variable “statusProcess” with the value “PAYMENT_FAILURE” in another place of the same process, you will have an optimisticLocking.

Below I will list some cases that can generate this error so that you can be careful and think better when modeling:

Completing a User Task simultaneously
If two or more users try to complete the same task at the same time, a conflict may occur. Only one of them will be able to, and the others will encounter an Optimistic Locking error.

Concurrent executions in parallel processes

In processes with parallel activities through a parallel gateway, two executions may try to update the same process instance simultaneously. For example, if both executions try to complete the same subprocess or task.

Timers or automatic events firing simultaneously

If there are multiple timers or automatic events firing at the same time for the same process instance, this may cause concurrent attempts to update the same entity in the Camunda database.

Concurrent updates of process variables

When different executions try to update process variables at the same time, the process version may not match and result in an optimistic locking error.

Transaction Compensation

When compensating for failed activities, if multiple transactions attempt to modify the same process instance, this may cause an optimistic locking error.

Event Instances in Subprocesses

When event subprocesses attempt to access or modify the same process instance, the database may detect a conflicting version.

Conflict between listeners or event handlers

Listeners or event handlers that fire simultaneously may attempt to modify data in a context that has already been modified by another execution, leading to an error.

I hope this helps!
William Robert Alves