ENGINE-03005 Execution of UPDATE VariableInstanceEntity

Hi guys,

I get this error when I call a saveTask:

Caused by: org.camunda.bpm.engine.OptimisticLockingException: ENGINE-03005 Execution of 'UPDATE VariableInstanceEntity[f365ac8b-f483-11e8-b03a-8416f905c9a2]' failed. Entity was updated by another transaction concurrently.
	at org.camunda.bpm.engine.impl.db.EnginePersistenceLogger.concurrentUpdateDbEntityException(EnginePersistenceLogger.java:130) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.handleOptimisticLockingException(DbEntityManager.java:406) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.checkFlushResults(DbEntityManager.java:365) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.flushDbOperations(DbEntityManager.java:345) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.flushDbOperationManager(DbEntityManager.java:314) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.flush(DbEntityManager.java:286) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:203) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandContext.close(CommandContext.java:132) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:113) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.interceptor.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:58) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:66) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.TaskServiceImpl.setVariables(TaskServiceImpl.java:293) [camunda-engine-7.8.0.jar:7.8.0]
	at org.camunda.bpm.engine.impl.TaskServiceImpl.setVariables(TaskServiceImpl.java:284) [camunda-engine-7.8.0.jar:7.8.0]
	at sun.reflect.GeneratedMethodAccessor10542.invoke(Unknown Source) [:1.7.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
	at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:45) [weld-core-1.1.23.Final-redhat-1.jar:1.1.23.Final-redhat-1]
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105) [weld-core-1.1.23.Final-redhat-1.jar:1.1.23.Final-redhat-1]
	at org.jboss.weld.proxies.TaskService$1783757836$Proxy$_$$_WeldClientProxy.setVariables(TaskService$1783757836$Proxy$_$$_WeldClientProxy.java)
	at es.gc.epsilon.core.api.processes.manager.TasksBaseManagerImpl.updateTaskVariables(TasksBaseManagerImpl.java:219) [classes:]
	at es.gc.epsilon.core.api.processes.manager.ProcessActionBaseManagerImpl.saveTask(ProcessActionBaseManagerImpl.java:162) [classes:]
	at sun.reflect.GeneratedMethodAccessor10531.invoke(Unknown Source) [:1.7.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) [jboss-as-ee-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) [jboss-as-ee-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:86) [jboss-as-weld-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:97) [jboss-as-weld-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) [jboss-as-ee-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at es.gc.epsilon.core.api.utils.interceptor.AuditReadInterceptor.auditRead(AuditReadInterceptor.java:19) [classes:]
	at sun.reflect.GeneratedMethodAccessor2616.invoke(Unknown Source) [:1.7.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) [jboss-as-ee-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) [jboss-as-ee-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:49) [jboss-as-ejb3-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:73) [jboss-as-weld-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]

But anyway the process instance seems to go on successfully…
Also, by writing some logs it seems that it’s being caused by trying to save variables for the same task but for different processInstances.
In order to reproduce it I have to launch several processInsances simultaneously.

Do you hava any possible explanation about what’s going on and possible solutions?
Thanks in advance.

1 Like

BTW, I had a look to this other incident:

I set jobExecutorActivate inside to true but still doesn’t work:
<?xml version="1.0" encoding="UTF-8" ?>

<!-- Before camunda version 7.2 process key-length must be lower than 25 -->

<process-archive name="epsilon">
    <process-engine>default</process-engine>
    <properties>
        <property name="isDeleteUponUndeploy">false</property>
        <property name="isScanForProcessDefinitions">true</property>
        <property name="jobExecutorActivate">true</property>
    </properties>
</process-archive>

</process-application>

My code creates several parallel threads, and then inside every thread I call an EJB method wich calls saveTask three times and finally issues another EJB call which calls one completeTask.

I’m using Camunda 7.8 and JBoss EAP 6.4.

Hi @alfmateos,

OptimsticLockingException is to be expected when multiple transactions update the same data in parallel. See https://docs.camunda.org/manual/7.9/user-guide/process-engine/transactions-in-processes/#optimistic-locking for an introduction to optimistic locking in the context of Camunda.

Cheers,
Thorben

Hi Thorben,

But our situation is:

We create a loop which opens a new thread. Every thread will execute saveTask / completeTask on its own ProcessInstance. One thread does not handle other thread’s processInstance at all.

Then, in that new thread we sequentially call three saves for the same task and one completeTask.

Do you mean that even when every thread manages its own processInstance this error will appear, just because they are executed in parallel? I thought that concurrency was handled in a (processInstance, task) basis, not in a (task) basis. Can you please clarify an answer to this?

Thanks a lot, Thorben.
Best Regards,
Alfonso.

What I mean is that these threads are managing the variables of the same task and the same processdefinition, but a different processInstance.

In such situation I should not get that OptimisticLockException, should I?

Thanks in advance,
Greetings
Alfonso.

Hi Thorben,

I realized that the problem appears at saveTask, but it really happens when we do, from several threads:

startProcessInstance (with variables map) → several setVariables(taskId, variables Map) → saveTask

I tried to reproduce the error in this incident:

does this clarify something else about a possible cause of this?
Thanks in advance.

Hi @thorben,
Were we able to fix this issue?
I am facing the exact same issue when I run a very simple bpmn workflow, that has only 2 service tasks. First service task sets some variable to the context. Second service task reads those variables from the context. This error happens when I run 3-4 of them concurrently.

Details of environment:
Camunda version: 7.9.0
MSSQL Server: 6.1.0.jre8
Stack trace is exactly same.

Hi All,

Any solution for above issue. We also getting this issue.