Lock not released for the same user with different requestor
When user session dies/accidentally closed and he tries to login from a different node - Pega doesn't handover the workobject lock previously held by this user in the new session/requestor. I am looking at info to understand the logic behind this design for live setups, as userid must be recognisable instead its requestor, which is always transient. It introduces delays and impacts the user experience. Especaily when it happens many hundred times like in our environment. So scenarios where gracious logoff hasn't happened - users will always end up in this situation.
Can someone also let me know how lock cache works as we tried putting unlock logic in our activity which seems to be not working all the time either.
The problem I have highlighted is similar to this support article where suggestion is to disable the lock cache. https://community.pega.com/support/support-articles/failing-release-lock-same-user-different-requestor .
***Edited by Moderator Marissa to add SA-ID to post***
PEG
GB
I'm not sure if this behaviour is correct or not.
But I wouldn't expect to be presented with a screen to release the lock, if the conditions to release the lock hadn't already verified as valid.
Which version are you using here?
PEG
GB
OK. So I've tried the same in my environment, but the lock is getting removed regardless of whether I'm connected to the same node or a different node (both nodes were up throughout this test).
I don't have a setting for database/lockcache/enabled in my environment, so this defaults to true.
I'll try to look into the mechanism further.
Incidentally are you able to try the above setting and see if this makes a difference for you?
PayPal
IN
Thanks for looking into this. I feel setting it to 'false' will help our environment but don't know what would we loose in the process.It seems you aren't able to reproduce. We aren't either everytime.
If there's a clear documentation on lock cache we could have taken informed decision.
PEG
GB
I'm afraid I've not managed to find any posts/documents which describe this yet.
I was debugging through the code. But there appears to be a different route which appears to be dependent on whether you have an EAR or WAR deployment.
Can you verify which you have here?
PEG
GB
I've been debugging through the code to see if I can find a point where it could potentially lead to the behaviour that you're seeing, but unfortunately I've not managed to find any leads.
With this caching enabled (which again it is by default) then this should cause the system to check the internal cache (Hashmap) to see if it is aware of the lock. This will be maintained by communication across the running nodes.
I assume that this was found initially (hence the screen which tells you of the lock). When releasing it will still perform the query on PR_SYS_LOCKS, then attempt to remove the lock from the hashmap and then from the table. But I wasn't able to ascertain why this might be failing without reason.
For the cache setting, this will allow the individual nodes to check which locks it's aware of without the need to query the database. If you disable this, then it will of course need to issue a DB query to check for a lock.
As this is deemed to be a remedy for the problem, you may wish to disable this.
If you're subsequently seeing contention on the PR_SYS_LOCKS table, then you may want to revisit this decision. But I expect it may be a difficult diagnosis.
PayPal
IN
Thanks Laurence for your answer. I see on other threads that it is sensitive to play around with this setting but we don't see enough documentation on its behaviour. I was puzzled to know it depends on ear or war deployment. The default behaviour should have been other way around. We will go forward with disablement of cache as the behaviour is not as per our expectation. If we are seeing contention on the lock table, we will take the SR route.