IDM WorkpointEJBException: Concurrency error

Products

• CA Identity Manager
• CA Identity Governance
• CA Identity Portal

Issue/Introduction

The following error appears several times in the JBoss application server logs. It appears to be benign. It does not impact the approval of work items. Per the stack trace, this stems from Workpoint alerts. Why is this appearing? What can be done to remediate it?

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

Release:
Component: IDMGR

Resolution

The log message from Workpoint indicating a “Concurrency error”, is saying that there are two calls to Workpoint server trying to update the same Job at the same time and only one will win.  The one that wins will update the Job with their requested updates and the other caller receives the error. You may have noticed that Workpoint runs faster In Workpoint 3.52 which can increase the number of concurrency issues as processing is faster. 
 
Concurrency could happen on a node that contains Multiple Library objects configured because the Monitors, which are multi-threaded processes, could process two library objects at the same time.  For instance, if you have multiple Async Rules configured on a node and more than 1 Async Rule script updates the Job ( via a workitem state change or a job state change), you will want to update the process to use the Run-Order to prevent a concurrency error.  The run-order forces the Async Rules to be executed in the order configured, thus single-threaded execution. If possible, you should combined the updates to the Job into a single script that is position at the end of the run-order. 
 
The Agent Run-order is available in Sync or Async Rules.  This configuration tells the server to execute the scripts single-threaded, one at a time in the order you specify.  This will prevent multiple Actions Scripts configured in the Agent’s Sync or Async panel to be executed at the same time.
 
However, there are multiple clients that could update the Job at the same time.  We focused on the Agent Rules on Activities, there are Delay nodes, Alerts, and Mail objects that are being processed by Workpoint Monitors along with the surrounding application could be completing work for an activity in the same job.  Any two clients that are updating the Job at the same time could collide and one client’s request will be rejected with the concurrency error.
 
With Jobs that have multiple nodes that can be processed at the same time, the best practice is to always code for the potential concurrency and catch the error and execute the request again.  The Monitors have this best practice implemented, so you may see the concurrency error in the log from the Alert monitor, but the Alert monitor will retry the configured number of times before it places the Job in the Error State.
 
Workpoint suggested to change the code in the Async Rules and Alerts to only have 1 library object on the Activity node that updates the job.  We also suggested to change the code to catch the concurrency error and retry in both the scripts and the surrounding application that could complete the activity.   
 
The following example shows the Concurrency Error at the end of the log file; it indicates the Alert is trying to save the Job (Job 1483238:WPDS) in the call WorkpointRules.imEscalate

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 you look at the Job (Job 1483238:WPDS) and it is still processing and the outcome of the Alert is seen (i.e. a User Data value was updated), that means the Alert Monitor probably reran the Alert Action a second time successfully.

 
Again to prevent the Concurrency, you need to look at all of the Job’s associated Library objects to see if there could be 2 clients, either the Workpoint monitors or the surrounding application saving the Job at the same time.  Remember a WorkitemEntry.ChangeState method being called in the surrounding application will update and save the Job.
 
If the Surrounding application will complete the Activity node, then the activity node’s associating Library objects, Actions, Alerts, Mail objects should not be performing a Job.Save at the same time.  If a Job needs to be updated, the Activity node’s Agent - Sync Action Rules can update the Job and Workpoint will save the job during the Job Evaluation.