Force Release Lock
Hi Guys,
I have a requirement which allow the agent to release the workobject lock even if it's still held by other requestor, so it can be reprocess immediately. I'm aware that this is not best practice due to data integrity and security. Is there a way to do that using Pega Api? I tried several ways but to no avail. Workunlock is not working even if you tick different requestor. I also tried to removed directly from system locks table and set the pxlockhandle to empty but still not working since version 6.
Please help.
Thanks!
***16/10/2017 Updated by moderator: Lochan to close post since user communicated a change in business decision regarding this requirement.***
Pegasystems Inc.
IN
Hi,
So in the agent activity, as a first step, you wanted to check if the lock is held on the WO. If lock is held, you wanted to remove it ?
May be tracing the agent activity helps ?
a) you can cross check if the activity WorkUnlock/ReleaseLock is getting called at all or not
b) And the corresponding entries in the db table pr_sys_locks are getting deleted or not
Do you face any error while agent is processing ?(How did you determine that lock hasn't been released)
Also please do check the below link, if it helps :
https://pdn.pega.com/community/product-support/question/how-force-remove-lock-belongs-another-operator
https://pdn.pega.com/community/pega-product-support/question/what-does-pega-recommend-check-during-lock-scenariosfor-ex
CSC
PH
Hi,
Yes I did everything, the activities are being called and the entry on sys locks table wasn't deleted. I got error message.."cannot obtain lock since locked is held by other user/requestor".
Pegasystems
US
First of all, if the lock is held by someone with a different operator name than you, you can't do it.
But if the other requestor has the same operator name, you can learn how to do it like this:
1) In IE browser, open some work so you're in the normal perform harness.
2) In Chrome browser, attempt to open the same work so you get the "object is already locked, would you like to kill the other requestor to release the lock?" message (This probably isn't the exact wording).
3) Turn on tracer and say "yes" to the question posed in number 2, and then you'll be able to find out in the tracer what rules to look at so you can learn how to do it yourself.
/Eric
PEG
US
As you have already learned, the locking architecture has changed in the 7 release, and what worked formerly will no longer work. Other complications which you may not have taken into account: If you are in a multi-node system and you want to release a lock held on another node, then even if the lock is held by another version of you, there will be some time-delay before that lock is released. There is no SLA associated with this, i.e., it can take any amount of time until it is finally released.
If you are experiencing problems with locks being held long after the holding user has gone away, you may want to experiment with shortening the time before a lock becomes "soft" and any user can "steal it".
The lock "timeout" interval is actually the amount of time after a lock is held before it goes "soft". Locks are by default kept in the lock table for 3 days before they are wiped. However, if you have your standard lock timeout set to 2 hours, then after the 2-hour mark, anyone requesting the lock will be able to get it. The original user will own the lock up until the 3-day deletion mark, but if someone else requests it after those 2 hours, that someone else will get it, and the original user will lose it.
As you have already learned, the locking architecture has changed in the 7 release, and what worked formerly will no longer work. Other complications which you may not have taken into account: If you are in a multi-node system and you want to release a lock held on another node, then even if the lock is held by another version of you, there will be some time-delay before that lock is released. There is no SLA associated with this, i.e., it can take any amount of time until it is finally released.
If you are experiencing problems with locks being held long after the holding user has gone away, you may want to experiment with shortening the time before a lock becomes "soft" and any user can "steal it".
The lock "timeout" interval is actually the amount of time after a lock is held before it goes "soft". Locks are by default kept in the lock table for 3 days before they are wiped. However, if you have your standard lock timeout set to 2 hours, then after the 2-hour mark, anyone requesting the lock will be able to get it. The original user will own the lock up until the 3-day deletion mark, but if someone else requests it after those 2 hours, that someone else will get it, and the original user will lose it.
If your goal is to eliminate locks which have been held for long periods of time but still less than 2 hours, you may want to consider shortening the lock timeout. Perhaps 15 minutes is still reasonable and eliminates your requirement to force-release a lock? I would expect that normally locks are held for less than a minute?
Open Record Explorer and click SysAdmin/System. You will see a list of 1 or more System records on the right. Select your system and you will be able to edit the lock timeout. This assumes that you have sufficient privileges to edit this record.
You can also configure a lock timeout for a case in the case designer Locking configuration or on the Advanced tab in the case type rule.
Phalanx Consultancy Limited
GB
Is there any setting that can be applied in v7 (7.1.5 specifically) to turn off the Lock details being held in the cache (pre v6.3)?
Infosys
AU
To keep it short, you can release lock held by a different requestor if the operator ID of the requestor which holds the lock and the operator ID of the requestor which tries releasing the lock are same. However this might take time if it is a multi node environment with caching of the locks enabled. If this is enabed the release of the lock might not appear immediately.
However if you are trying to release lock held by a different requestor logged in with different ID , this would not work.