TimerEntity was updated by another transaction concurrently

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

bardioc

Hello,

I've created a simple test case to show a optimistic locking error with the TimerCatchEvent. I've tried to build a unit test from this, but somehow it only occurs when directly implemented in the process.

We're currently using WebSphere 8.0, Activiti-5.9-SNAPSHOT as well as Oracle as DB for the persistence. The model used for this test is the same as found in the IntermediateTimerTest-case in the activiti-engine test suite.

[attachment=0]IntermediateTimerTest.png[/attachment]

The timer is configured as PT5S.

I'm creating a singleton process engine with the EJB-Annotation @Singleton and @Startup. The configuration utilizes the Spring based UOWTransaction manager required for WebSphere.

    <bean id="transactionManager" class="org.springframework.transaction.jta.WebSphereUowTransactionManager" />
    
    <bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">    
        <property name="jobExecutorActivate" value="false" />      
        <property name="transactionManager"  ref="transactionManager" /> 
    </bean>
‍‍‍‍‍‍‍‍

The database is retrieved via @Resource annotation to utilize the currently active transaction.

conf.setJobExecutorActivate(true);
conf.setDataSource(dataSource);
conf.setHistory(ProcessEngineConfiguration.HISTORY_ACTIVITY);
conf.setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_TRUE);
‍‍‍‍‍‍

When I afterwards create two process instances directly after each other:

final ProcessInstance instance
    = engine.getRuntimeService().startProcessInstanceByKey("IntermediateTimerTest");

final ProcessInstance instance2
    = engine.getRuntimeService().startProcessInstanceByKey("IntermediateTimerTest");
‍‍‍‍‍‍‍

Both fall into the timer. When the timer fires an exception is thrown:

[21.10.11 11:40:09:084 CEST] 00000026 CommandContex E   Error while closing command context
org.activiti.engine.ActivitiOptimisticLockingException: TimerEntity[311] was updated by another transaction concurrently
   at org.activiti.engine.impl.db.DbSqlSession.flushUpdates(DbSqlSession.java:435)
   at org.activiti.engine.impl.db.DbSqlSession.flush(DbSqlSession.java:348)
   at org.activiti.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:147)
   at org.activiti.engine.impl.interceptor.CommandContext.close(CommandContext.java:103)
   at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:49)
   at org.activiti.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:42)
   at org.springframework.transaction.jta.WebSphereUowTransactionManager$UOWActionAdapter.run(WebSphereUowTransactionManager.java:337)
   at com.ibm.ws.uow.EmbeddableUOWManagerImpl.runUnderNewUOW(EmbeddableUOWManagerImpl.java:786)
   at com.ibm.ws.uow.EmbeddableUOWManagerImpl.runUnderUOW(EmbeddableUOWManagerImpl.java:365)
   at org.springframework.transaction.jta.WebSphereUowTransactionManager.execute(WebSphereUowTransactionManager.java:281)
   at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:124)
   at org.activiti.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:40)
   at org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:33)
   at org.activiti.engine.impl.jobexecutor.JobAcquisitionThread.run(JobAcquisitionThread.java:63)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Can somebody please help me to understand, what I did wrong or is this a bug in the system?

Thank you very much!

IntermediateTimerTest.png

bardioc

I found out, that in the exception, the flushUpdates in DbSqlSession checks, whether exactly 1 row is updated:

<br>&nbsp; protected void flushUpdates(List<PersistentObject> updatedObjects) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // &hellip; left out code<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int updatedRecords = sqlSession.update(updateStatement, updatedObject);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (updatedRecords!=1) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw new ActivitiOptimisticLockingException(toString(updatedObject)+" was updated by another transaction concurrently");<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; updatedObjects.clear();<br>&nbsp; }<br>
The method is called first for a TimerEntity (hash A) resulting in 1 update, the second time for another Timer Entity (hash resulting in 0 updates. This second call leads to the exception. However, why should this be a concurrent update, if nothing has been updated?

I found out, that actually, TimerEntity (hash A) and Timer Entity (Hash reflect the same timer. Both created by the JobAcquisitionThread. It seems, the JobAcquisitonThread runs once through its 'run()' method to execute the timer, and then again on its next 'run()' finds the timer once more. Thats why the second call leads to the concurrent update.

I'll try to dig deeper into this code and to find out, how one can prevent the Acquisition thread from finding the same timer again.