Work item XXXXXXXX locked by user XXXXXXX (enqueue error)

[pksurya]

I have an issue with Appropriation request workflow process.

There are 4 approval levels. Agent indentification and approval happens in a loop.

Occasionally, the workitem fails with the message 'Work item XXXXXXXX locked by user XXXXXXX (enqueue error)' The workitem is  getting locked by the previous approver. Is there any specific reason for this lock or do I need to add a wait step for each loop?

The approver, approves the workitem from his Business Workplace. I checked other threads, but I am not able to figure out a reason. These are all synchronous processes.

'Index access to agent tables' is a background step?

Thanks,

Surya

[hugo_amo · Accepted solution]

Hi Surya,

There is a workitem enqueue when you execute a work item which will not be released until the work item execution is Canceled or finished.

The work item enqueue was introduced in order to eliminate database inconsistencies and the note 982592 explains the behaviour.

982592 - Enqueue lock during the execution

The locking message is probably a temporary enqueue lock. When this happens an entry is written to table SWP_SUSPEN and when the lock is released RSWWERRE restarts the work item once again.

In older releases, and earlier sp levels, the workflows didn't run into locking situations with a well defined handling procedure (log entry, SWP_SUSPEN, RSWWERRE), but ran into database deadlocks once in a while which led to incurably corrupted workflows.

Now the workflow itself (Parent work item ID) can be enqueued and this may cause and locking conflict when a dialog or background step executes.

Check if your workflow customizing is incomplete using transaction SWU3. Also, I would recommend to reschedule all the background jobs and see if the issue persists.

If you need to change the locking behaviour of your workflow then review the note 1122756.

1122756 - Extended lock behavior for workflow runtime.

Another thing: Within that workflow there are some more locking conflicts when the steps waiting for the events perform their callback. These locking conflicts can probably be avoided by the means of note 1499149.

Hope this information helps.

Regards,
Hugo

[pksurya · Accepted solution]

Thanks Hugo.

I could see that the job which runs the program RSWWERRE has been turned off. I believe this could be the reason why the locked workitems are not restarted automatically. Is that correct?

Thanks,

Surya

[hugo_amo · Accepted solution]

Yes, you are right