Support Article
Lock issue on PRPC 6.3
SA-945
Summary
The Developer has written custom activities based on PRPC 6.2 that manipulate PRPC locks on workobjects. This contravenes Guardrail compliance, as Lock Handling should be left to the Engine.
After an upgrade to PRPC 6.3 SP1, these direct lock manipulation activities no longer work.
Root Cause
The PRPC Lock implementation changed in 6.3, please see the Developer Help on this subject :
https://pdn.pega.com/sites/default/files/help_v63sp1/Default.htm#concepts/concepts2/conceptslocking.htm
In PRPC v6.3 and above, lock information is held in the memory of each node, rather than in the database alone, for improved performance.
Resolution
The locking mechanism change in v6.3 results in both the pr_sys_locks DB table and an in memory cache being maintained.
Prior to v6.3 there was no in memory cache.
The main purpose of the cache is to reduce the i/o associated with calls to the DB to verify if the requestor already has a lock on an object or not.
This change has negated the way some earlier "unlock" APIs functioned, and if you now try to delete rows directly from the pr_sys_locks table, this can result in dangling/hanging locks in the memory resident cache.
It is still possible to revert to the pre-v6.3 "classic" lock management scheme, where the locks reside only in the DB resident pr_sys_locks table via the prconfig setting "database/lockcache/enabled". A value of "false" for this prconfig setting results in the memory resident lock cache being disabled.
The "database/lockcache/enabled" configuration option can also be defined as a Dynamic-System-Setting.
Published June 12, 2015 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.