02-23-2018 01:01 PM
We have a bpmn definition, using which we generate about 70K workflows each quarter. All this time, we were creating workflows only in one database. There is an organizational pitch to create workflows in multiple databases. After we introuduced multiple database configuration, we noticed optimisticlock exception while generating 70K workflows.
We do not see any loss of workflow data, however, we see the exception which bothers us.
To throw some light, we have in our xml - three different jndi to three different databases.
Each of the jndi source have their own transaction manager.
<bean id="processEngineConfiguration" class="class extends org.activiti.spring.SpringProcessEngineConfiguration">
<property name="dataSource" ref="dataSource" />
<property name="dataSourceJndiName" value="#{jndiUrls.jndiWFEngine}" />
<property name="transactionManager" ref="transactionManager" />
<property name="databaseSchemaUpdate" value="true" />
<property name="jobExecutorActivate" value="true" />
<property name="enableDatabaseEventLogging" value="true" />
<property name="activityBehaviorFactory" ref="activityBehaviorFactory"/>
</bean>
We have the above configuration for each datasource. After introducing this configuration, we see optimisticlock exception. Stack trace is:
RuntimeService.postTaskForm(): exception: org.activiti.engine.ActivitiOptimisticLockingException: HistoricVariableInstanceEntity[id=0b532b38-1319-11e8-9dc9-005056bddfe9, name=PreparerSecGroup, revision=0, type=string, textValue=something] was updated by another transaction concurrently.
Can you please provide some pointers on how to resolve this error?
we do not have this issue when we are working with a single database.
02-26-2018 01:43 AM
Yes I would expect there not to be any data loss. An issue like this was discussed recently and in that case also there was no data loss JobEntity [id=*****] was updated by another transaction concurrently The error suggests that two engines are trying to do the same thing at the same time and only one of them therefore succeeds (i.e. a race condition). As covered in the referenced thread, this is more likely to happen with async tasks and more likely with v5 than v6. Are you seeing the error on an async task/s? If you could share your process definition and which part you see the error on that would help. From the error it looks like you have a form on a task - is the error always related to that form? Are you using v5?
02-26-2018 06:39 AM
02-26-2018 07:41 AM
I suspect the parallelGateway is the reason the jobExecutor is in use even though you don't have anything explicitly marked async. You could try turning off jobExecutorActivate and asyncExecutor (using settings in clustering with async tasks and the async executor ) see if it all still works. Other paths available to try are switching to the async job executor and/or upgrading to v6. Other threads on this are using asyncExecutor but ActivitiOptimisticLockingException on activiti 5.21.0 and Enable jobExecutorActivate - Impact .
02-27-2018 12:07 PM
Hi Ryan,
If we turn off jobExecutorActivate, then when the user takes action, would the workflow state move forward?
Explore our Alfresco products with the links below. Use labels to filter content by product module.