Lock issue on PRPC 6.3
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.
The PRPC Lock implementation changed in 6.3, please see the Developer Help on this subject :
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.
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.
0% found this useful