JobEntity was updated by another transaction concurrently exception when using workflows in OpenIDM 4.x

Last updated Jan 5, 2021

The purpose of this article is to provide assistance if you receive a "SEVERE: exception during job execution: JobEntity [id=1234] was updated by another transaction concurrently" exception when using workflows in OpenIDM 4.x. This issue only affects JDBC repositories.


This article has been archived and is no longer maintained by ForgeRock.


The following error is shown in the OpenIDM log when using a workflow task:

Aug 24, 2016 11:17:33 AM org.activiti.engine.impl.jobexecutor.ExecuteJobsRunnable run SEVERE: exception during job execution: JobEntity [id=7727] was updated by another transaction concurrently org.activiti.engine.ActivitiOptimisticLockingException: JobEntity [id=7727] was updated by another transaction concurrently at org.activiti.engine.impl.db.DbSqlSession$CheckedDeleteOperation.execute( at org.activiti.engine.impl.db.DbSqlSession.flushDeletes( at org.activiti.engine.impl.db.DbSqlSession.flush( at org.activiti.engine.impl.interceptor.CommandContext.flushSessions( at org.activiti.engine.impl.interceptor.CommandContext.close( at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute( at org.activiti.engine.impl.interceptor.JtaTransactionInterceptor.execute( at org.activiti.engine.impl.interceptor.LogInterceptor.execute( at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute( at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute( at at java.util.concurrent.ThreadPoolExecutor.runWorker( at java.util.concurrent.ThreadPoolExecutor$ at

This is an intermittent error and will not occur every single time. 

Recent Changes

Upgraded to, or installed OpenIDM 4.x.

Implemented the workflow functionality.


The Activiti Workflow module was modified in OpenIDM 4.0 to use the same connection pool as the repository, which means that both Activiti and the repository module now share the same transaction manager.


This issue can be resolved by upgrading to IDM 5 or later; you can download this from BackStage.


Alternatively, this issue can be resolved by separating the Activiti datasource away from the repository datasource to mimic the setup in earlier versions of OpenIDM. You can do this by creating a separate datasource for Activiti and then configuring the workflow to use this new datasource:

  1. Shutdown the OpenIDM instance.
  2. Copy the datasource.jdbc-default.json file applicable to your repository type (for example, from the /path/to/openidm/db/postgresql/conf directory if you are using the PostgreSQL® repository) to the /path/to/openidm/conf directory and rename it datasource.jdbc-activiti.json. You will now have two database connection configuration files in this directory.
  3. Update workflow.json (located in the /path/to/openidm/conf directory) and change the useDataSource from default to activiti so that it uses the new database connection configuration file: { "enabled" : true, "useDataSource" : "activiti", "workflowDirectory" : "&{launcher.project.location}/workflow" }
  4. Delete the contents of the /path/to/openidm/felix-cache directory.
  5. Restart the OpenIDM instance.

These changes will increase the number of connections since you will have two separate connection pools. You can manage the connection pools for both the repository and the Activiti module as described in How do I configure the connection pool for the managed repository in OpenIDM 4.x? by applying the changes to the relevant datasource.jdbc-default.json file.

See Also

OpenIDM 4 Release Notes › Major Changes to Existing Functionality

Related Training


Related Issue Tracker IDs

OPENIDM-6193 (JobEntity was updated by another transaction concurrently)

OPENIDM-5482 (Tasks in UI cause random server errors when updating/assigning tasks)

Copyright and Trademarks Copyright © 2021 ForgeRock, all rights reserved.