TimerEntity[XXXXXX] was updated by another transaction concurrently

[swamy2156]

Hi,

I wrote  a process with timer boundary event & a service task. For every 2 minutes serviceTask will be called and send some notifications(linux box#1 where jobExecutorActivate = true)
I wrote a service to complete the human task( linux box#2 - where jobExecutorActivate = false). Occassionally while updating the task using the service which I written I am getting this error
                            "TimerEntity[XXXXXXX] was updated by another transaction concurrently"
in perticular scenarios where updating the task and timer event executed simultaniously.

box#1 processEngine configuration is as follows.

  <bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">
    <property name="dataSource" ref="dataSource" />
    <property name="transactionManager" ref="transactionManager" />
    <property name="history" value="full" />
    <property name="databaseSchemaUpdate" value="false" />
    <property name="jobExecutorActivate" value="true" />
    <property name="jobExecutor">
      <bean class="org.activiti.engine.impl.jobexecutor.DefaultJobExecutor">
        <property name="corePoolSize" value="1"/>
        <property name="maxPoolSize" value="1"/>
      </bean>
    </property>
    <property name="jdbcPingEnabled" value="true" />
    <property name="jdbcPingQuery" value="select 1" />
    <property name="processDefinitionCacheLimit" value="20" />
    <property name="processEngineName" value="default"></property>
    <property name="customSessionFactories">
      <list>
        <bean class="com.uprr.bpm.rest.services.ldap.LDAPUserManagerFactory">
          <constructor-arg ref="ldapConnectionParams" />
        </bean>
        <bean class="com.uprr.bpm.rest.services.ldap.LDAPGroupManagerFactory">
          <constructor-arg ref="ldapConnectionParams" />
        </bean>
      </list>
    </property>
  </bean>
  <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource" />
  </bean>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Any help will be really appreciated.

Thanks,
Swamy.

[frederikherema1]

That's perfectly normal, that exception. It means the optimistic locking stategy works, as the transaction the "job execution" was in will not be committed due to the fact that the user-task is completed and the timer doesn't exist anymore (that's what I'm guessing).

Its a specific Activiti exception-type (ActivitiOptimisticLockException) and can occur in situations you're describing (simultaneous modification of timer state). The transaction that is first, wins. The other is rolled back…

[swamy2156]

Thanks for your reply Fred!!

In my case what happens is, update task service completes the task and taskListener publishes that complete event. Because of OptimisticLockException, transaction get rollback but not able to control event publish thing. Because by the time process reaches OptimisticLockException, taskEvent fired and after that transaction rolled back which is not appropriate I think.

Instead of other transaction rollback, can we do complete the transactions one after another? or Is it possible to handle taskEvent firing when OptimisticLockException occurred.

-
Swamy.

[jbarrez]

No, what you are asking is to make the firing of the event part of the transaction.
If you are not using transactional resources this simply cannot be done …
One option is to use JMS (which can do JTA) but that is of course a serious heavy weight solution.

[frederikherema1]

If you're using spring, you can always add a TransactionSynchronisationAdapter to the transaction-context instead of directly "publishing" the event. When the adapter's callback-method is called when transaction is committed, you can publish the event from within the TransactionSynchronisationAdapter. Offcourse, if something goes wrong here, the process-state is already committed and it seems that noting has gone wrong on the activiti-side. This is a path you should cover yourself…