Isolated case of OptimisticLockingException

Camunda 7 Topics Discussion & Questions
1

Hello everybody.
We got an “OptimisticLockingException” during the execution of our daily workflow.
This is the only isolated case of this exception in our workflow since it started running more than one year.
The Exception in the log is traces as WARN so it does not provide any additional information.
From the last INFO log we have identified the part of the flow that has been involved in this problem and does not seems that in that part there is parallelism.
When we got the error from the Camunda interface there was 2 job, both in pending status, associated to the same process.
I would like to know what happens and which could be the possible causes.
I’m also wondering if there is some way to try to replicate it and if we can actuate some solution for catching this error and try to stop one job and restarting the other one to permit the workflow to continue running.

Thanks in advance.

2

Hello my dear!
Welcome to our community :smiley:

OptimisticLocking usually occurs when Camunda tries to update the same variable or row in the database 2 times or more (for the same ID) at the same time, generating “concurrency”.

You need to identify through logs, where this exception is occurring, to handle it.

In some situations, depending on the case, OptimisticLocking is unavoidable, and if it is, it is possible to handle it through a queue/message (RabbitMQ, SQS, or others)… so that when this exception is generated, the sending attempt is made.

I had a case similar to yours, in which our process received a message event that updated a variable in Camunda, and when this event was fired massively very quickly, it generated optimistic locking.

We solved this by implementing an SQS queue, in which the events arrived first in this FIFO queue, and were being fired to Camunda one by one, if there was Optimistic, a retry was made in the sending, 1 every 3 seconds, during a maximum of 3 times.

After that, if it was unsuccessful, the queue sent the message to the DLQ (dead letter queue) and followed the process of sending the other events to the camunda.

But we would need to study your case to see if this would apply, or perhaps better modeling in the process will do the trick.

I hope this helps.

William Robert Alves