Locking Issue
I am facing an issue with the pega locks .I don't know if it is a pega issue or it is the default behavior .Somebody please reply to my post.
In my case I have specified the goal time as 15 minutes from the case creation time ,and the default locking time as 30 minutes .
The problem is even though the user is active on the case even after 30 minutes ,the sla agent is acquiring lock on the case and when the user submits the assignment ,he is getting an error saying .Please retry again .In the entire case creation time the user is in a screen flow .
I just want to know ,how come the agent is acquiring the lock on the work object when the user is active on the case.
Pegasystems Inc.
IN
When the goal event is passed, we update the audit history. Could you find audit related to goal event?
Pegasystems Inc.
IN
This is an expected behavior.
You must have configured Default locking for your Case.
Giving default locking time out as 30 minutes means after 30 minutes are passed and user is still working on it, lock will be converted to Soft lock.
Soft Lock : A soft lock is a lock that a user (or other requestor) has held by for too long, based on timeout parameters, and so is marked by the system as "expired." While locks ordinarily can be released only by the requestor who holds them, soft locks can be stolen from the requestor by another requestor.
Even though user was active for 30 min, as soon as 30 min are over, user was left with soft lock. And then SLA agent picked the assignment from queue and stole the lock from user and processed the case. Now when we try to submit the assignment, the issue you are getting is expected.
Let us know if this helps or in case you need any other information :)
incessant technologies
IN
Hi ,
Default locking is configured in my case (30 mins)
But soft lock will apply only if "User doesn't save the case for 30 mins. In my case user did save many times i.e. navigated couple of flow actions within 30 mins. So the lock can't be soft lock in my scenario." So how can you say that the lock was converted to soft lock ,because every time the user will save the case ,30 minutes would be calculated from that time ,so the agent shouldn't have the lock on the case ideally .
Pegasystems Inc.
IN
When you say Save the case, you meant flow action submit correct ? Because Save will not always release the lock and there will not be any impact on timer calculations.
If that is the case, then also Navigating between couple of flow actions will also not always reset the timer. Timer is started when lock is acquired and stopped when lock is released. When user is performing back to back assignments lock is acquired on first assignment only.
Say flow has Assignment 1 and Assignment 2 back to back routed to same operator. Then lock will only be acquired while performing assignment 1 and released after assignment 2 is finished.
Can you confirm below points from your scenario
- Check Audit that SLA agent did actually perform the case.
- And based on your reply I am assuming you were talking about Case SLA, not assignment SLA since you are talking about multiple flow actions ?
- Can you also check in tracer that these are back to back assignments and lock is not released in between
Updated: 12 May 2016 5:04 EDT
incessant technologies
IN
Hi ,
Yes by submit , I mean flow action submit .Your other queries :
1) Yes I checked the audit ,SLA agent did actually perform the case.
2)It is Case level SLA and not assignment SLA
3)Yes these are back to back assignments.
Is there a way I can check if the lock has become soft lock other than by checking the pr_sys_locks table .I don't have access to database in my project.
Thanks.
Pegasystems Inc.
IN
You can check directly at instances of System-Locks class or run InstanceList list view.
In that list view, you can add pxExpireDateTime as one of the columns by private check out. If expire time is already passed then it is considered as soft lock and can be acquired by someone else. Let us know in case of any other questions.
Thanks :)
Virtusa
IN
Did the user and agent are using same app server instance or the agent is running on separate server?? if different server instances are used, then timezone also should be same for both the instances