OptimisticLockingException during job execution caused by createVariableInstanceQuery


My process runs perfectly fine without any error even with some jobs being involved asynchronously.

For business reason, I need to query the current process state (just readonly query).
I noticed that doing so leads to OptimisticLockingException at the job executor level.
I perform my queries from a separate thread (not from a job of course)
I noticed that amongst the queries I do, the one retrieving variable instances seems to be causing the trouble.

List<VariableInstance> vars = runtimeService.createVariableInstanceQuery().executionIdIn(processId).list();

Again, I do not modify anything, I just read the variable names and values.

Find below the exception. Should not reading be totally safe ?


org.camunda.bpm.engine.OptimisticLockingException: ENGINE-03005 Execution of 'UPDATE VariableInstanceEntity[67640a3a-dc23-48b9-a40a-3adc2328b922]' failed. Entity was updated by another transaction concurrently.
	at org.camunda.bpm.engine.impl.db.EnginePersistenceLogger.concurrentUpdateDbEntityException(EnginePersistenceLogger.java:132) ~[camunda-engine-7.9.0.jar:7.9.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.handleOptimisticLockingException(DbEntityManager.java:484) ~[camunda-engine-7.9.0.jar:7.9.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.checkFlushResults(DbEntityManager.java:443) ~[camunda-engine-7.9.0.jar:7.9.0]
1 Like

I found out that if I query the variables with the disableCustomObjectDeserialization option, it works like a charm… hopes this help.

List<VariableInstance> vars = runtimeService.createVariableInstanceQuery().executionIdIn(processId).disableCustomObjectDeserialization().list();

1 Like

Hi @nicolas,

Which Camunda version do you use? I remember that we fixed a similar bug some time ago.


1 Like


We use Camunda 7.9.0


Hello @thorben
Camunda 7.16 still have this problem

7.17.0 has it, too :frowning:

Camunda docs say it needs TRANSACTION_READ_COMMITTED isolation level to avoid locks: Database Configuration | docs.camunda.org
I’m trying this now with my spring-boot app:

spring.datasource.hikari.transaction-isolation: TRANSACTION_READ_COMMITTED

Which, as I understands, is not a default mariadb configuration.