OptimisticLockingException caused by Entity was updated by another transaction concurrently

Camunda 7 Topics Discussion & Questions
1

Hi,

During load we are seeing bunch of OptimisticLockingException and I do understand that this exception is caused when multiple transactions are being executed in parallel and trying to update the same record, but we are not able to identify what in the model is causing this situation.

We do have nested process that span across 10-15 models with lot of inline scripting, when I query the act_hi_job_log table I see after job is created it attempted to execute transaction multiple times and failed, in some cases executed more than 200 times. Since the transaction includes executing an HTTP service task which creates users as part of task causing multiple user records to be created in end system.

How can I identify what is causing these concurrent transaction to happen?
“ENGINE-03005 Execution of ‘DELETE MessageEntity[8aa34594-28b9-11ed-abce-0ae50c7ccd2d]’ failed. Entity was updated by another transaction concurrently.”

image
image1612×858 177 KB

2

Hey @harish_malavade,

We have some documentation here that helps with diagnosing deadlocks: Logging | docs.camunda.org

The same loggers are also useful to understand optimistic locking exceptions. You will see which threads run which commands at which times (make sure your logging output includes thread ids/names) and which entities they modify in the database at the end of their commands. You can then analyze the logs around the occurrence of the exception and see which other transactions modified the same entities. The last step is then to deduce which business logic triggered the commands.

Cheers,
Thorben

3

Thank you @thorben for the response, I will try enabling additional logging on persistence to see if i get anything.

Do you know if the the job does not get open http thread could cause this issue? We have below setting in out tomcat,
I was thinking if we should increase minSpareThread counts in connector configuration

    <Connector
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="443" maxThreads="1000"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="###keystoreFile###" keystorePass="###keystorePass###"
           maxHttpHeaderSize="16384"
           clientAuth="false" sslProtocol="TLS"/>

    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
        maxThreads="1000" minSpareThreads="100"/>
4

No, I don’t think that’s it, at least not directly. The exception is really only thrown when there is a parallel modification in the database.

1 Like
5

Thanks, I could identify one model that had inclusive gateway with no wait state. We added asyncBefore on the inclusive gates and added asyncAfter on the call activities to break the transactions to avoid concurrent updates in the database

6