Question
Tata Consultancy Services
IN
Last activity: 30 Jun 2022 3:03 EDT
Optimistic Lock behaviour When end User and Pega Service updating same work object at same time
Optimistic Locking Issue
I am facing issue with optimistic locking,
when the user is having lock on the case and parallelly when Pega Service is trying to update the same work object it is getting error that other requestor is having lock though on Case type locking is defined as optimistic
Also, i have seen on case type that for optimistic locking there is no soft lock
Pegasystems Inc.
IN
Updated: 29 Jun 2022 9:15 EDT
Tata Consultancy Services
IN
HI Nishant, We have retry mechanism using the queue processor and it has max 3 intervals still in the queue process broken item in Admin studio I can see error coming as other requestor acquired lock on work object and clearly in case type locking mechanism is optimistic
Also, in service Rest activity when we unchecked the checkbox of lock and release on commit from obj-open it worked fine but is it right to have obj-open in update service rest activity without lock?
Pegasystems Inc.
IN
@SONIA ARORA
1) Is this issue happening sporadically?
2) Is there any application logic related to locking in this scenario?
Tata Consultancy Services
IN
Hi Nishant,
yes the issue is happening sporadically and in this scenario service is trying to create the new child case and close the previous created child case but before coming to this if the parent is locked by someone or this child then exception of other requestor has lock is occuring
Pegasystems Inc.
IN
@SONIA ARORA Hi Sonia, I have a few more questions:
1) On the service side, how is the child case being created? Which API is being used.
2) When the service is ending up with a broken queue item, What does the error message say? Is the requestor holding lock an operator or batch ?
@SONIA ARORA
When a user opens an assignment on any instance of the casetype configured with optimistic locking, lock on the work object is not acquired then. Instead a lock is acquired when a user submits the assignment. The lock is held till the case processing is completed. Usually case processing doesn’t take long as there is no manual intervention.
In your case, I think Pega service and case processing are trying to update the work object at the same moment and resulting in this issue. If that’s the case a simple solution is to use retry mechanism in your Pega service.
P.S Lock on a case is acquired so that concurrent updates don't happen(which may cause inconsistent case data).