IDM WorkpointEJBException: Concurrency error
Article ID: 130034
Updated On:
Products
Issue/Introduction
The following error appears frequently in the JBoss application server logs. It typically does not impact the final approval of work items and stems from Workpoint alerts processing in parallel:
2019-03-05 16:56:20,481 ERROR [org.jboss.as.ejb3.invocation] (Worker_alertq#AlertQ1#WPDS_12) JBAS014134: EJB Invocation failed on component JobUpdatePvt_EJB for method public abstract com.workpoint.common.data.JobData com.workpoint.server.pojo.JobUpdatePvt.save(java.lang.String,java.lang.String,com.workpoint.common.data.JobData,int) throws com.workpoint.server.ejb.WorkPointEJBException: com.workpoint.server.ejb.WorkPointEJBException: Concurrency error. Another user has updated this Job object since you selected it. Please re-select Job 1504948:WPDS and attempt this operation again.Environment
Identity Manager 14.x (All supported releases)
Cause
The Workpoint server log message "Concurrency error" indicates that two separate requests or processes attempted to update and save the same Job object simultaneously. Only one request wins and saves its changes, while the second request fails with a concurrency error.
Performance improvements in Workpoint 3.52 and later cause processing to run faster, which can increase the frequency of simultaneous job updates if workflow rules are not configured sequentially.
Common causes of concurrency issues include:
Multiple Library Objects on a Single Node: Multi-threaded Workpoint Monitors process library objects in parallel. If a node has multiple Asynchronous Rules configured and more than one rule script updates the job (via a work item or job state change), a race condition occurs.
Overlapping Clients: Multiple internal clients (such as Delay nodes, Alerts, Mail objects, or surrounding application API calls like
WorkitemEntry.ChangeState) updating the same job at the same time.
Resolution
To prevent and remediate Workpoint concurrency errors, follow these implementation best practices:
1. Enforce Execution Run-Order for Async Rules
Configure the Agent Run-order on your Synchronous or Asynchronous Rules. Setting a Run-order forces Workpoint to execute scripts sequentially in a single thread rather than in parallel, preventing concurrent execution of multiple Action Scripts on the same agent:
Configure the Run-Order on nodes containing multiple Asynchronous Rules so that execution occurs sequentially.
If possible, combine multiple job updates into a single script positioned at the end of the run-order sequence.
2. Restrict Job Updates per Activity Node
Simplify workflow logic so that only one library object per Activity node updates the job state or data.
Avoid having surrounding application calls complete an Activity node while associating Library objects, Actions, Alerts, or Mail objects simultaneously execute
Job.save().When a job needs updates, use the Activity node's Agent - Sync Action Rules to update the job so Workpoint saves it during standard job evaluation.
3. Implement Error Handling and Retries
In custom scripts, Async Rules, Alerts, and surrounding application callbacks, catch the concurrency error explicitly and implement a retry mechanism.
Built-in Monitor Retries: Workpoint Monitors already implement retry logic by default. If an Alert monitor encounters a concurrency error, it retries the operation up to the configured retry threshold before moving the job into an Error State.
Verification
If a concurrency error appears in the logs (as shown in the sample trace below), verify the final state of the job:
2019-03-05 16:56:20,454 ERROR [com.workpoint.server.pojo.GenericServerBean] (Worker_alertq#AlertQ1#WPDS_12) RecordSetException occurred: Concurrency error.
Error occurred in Statement #1 in Script ID 28:IMOB, Script Name = 'IM Escalate', Script type = 'Alert Check Condition'. Job ID = 1483238:WPDS
at com.workpoint.client.Job.save(Unknown Source) [wpClient.jar:]
at com.netegrity.ims.workflowCallbacks.WorkpointRules.imEscalate(WorkpointRules.java:295) [ims.jar:]
If the job (Job 1483238:WPDS) continues processing normally and the expected outcome (e.g., updated User Data values) is reflected, the Alert Monitor successfully completed the operation on its subsequent retry attempt.
Feedback
