Posted: 7 Feb 2019 3:48 EST Last activity: 13 Feb 2019 9:31 EST
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.
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.
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.
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.