Can you trace the SLA agent when it processes the wait step and check the Locking event type to see what is happening?

During normal flow processing, the work object is saved (for instance, in the RecalculateAndSave activity) and then committed (n the CommitWithErrorHandling activity), although if you have an error stack, you may be able to see more accurately where the save is being attempted.

A lock is required in order for that save to be allowed, and if you do not hold the lock, you get the error you showed above.

Some things to check:

1) If you're using flow processing, the system acquires the lock for you, but if you have to acquire it, such as with the "lock" checkmark on an obj-open, make sure you use something like the "StepStatusFail" test to make sure you actually got the lock.

2) As mentioned, flow processing normally does the obj-open for you, but if you happened to do it, see whether you used the "release on commit" checkmark, since if you did, and the lock got released during the commit, that could explain why you're getting the error.

3) Once you have the lock, if you're using flow processing, the system handles all the saves and commits for you, so you shouldn't have to do any obj-save.  But if you do, see whether you kept the lock or released it.

Ideally this should not occur as when you are using wait shape, the assignment will be at a default workbasket ( deferworkbasket mainly ).

I think this needs some more troubleshooting ( preferebly via screenshare etc ) . So I would recommend you to engage GCS for this by creating an SR.

Hi HariSureshBabu,

Please let us know if you do log an SR for this and its ID. That way we can track it and follow-up this discussion with the resolution.

Regards,

Lochan  |  Community Moderator  |  Pegasystems Inc.