Process Commander implements locks separately from the locking mechanism supplied by the database software (such as Oracle) that supports the PegaRULES database. Locks are exclusive to one Thread, and operate system-wide in a multi node Process Commander system.
A Process Commander requestor can lock an open instance if all of the following are true:
The instance belongs to a concrete class that has Allow Locking? checked in the class rule and
The instance has ever been saved and committed to the PegaRULES database.
The requestor has an access role that conveys the privilege needed.
Properties identified on the Locking tab of the Class rule form together define the lock identity. (If the Locking tab contains no property names, the properties that form a lock definition are the same as those that form the external key, on the Database tab.) All classes in one class group (which corresponds to one database table) have the same properties in the lock definition.
To view locks held by your own requestor session, select Designer Studio > Process and Rules > Tools > Work Admin > My Locks.
To view all locks held by any requestor, select Designer Studio > Process and Rules > Tools > Work Admin > All Locks and then drill down to identify the details of the locked object. Hold the mouse pointer over a row of the drill-down detail to identify the Operator ID of the requestor holding the lock.
These two reports present instances of the System-Locks class, corresponding to the pr_sys_locks table of the PegaRULES database.
Locks are acquired by activities, using one of three methods — Obj-Open, Obj-Open-by-Handle, and Obj-Refresh-and-Lock. Optionally, each of these methods can store detailed results in a page of class System-Locks. If a method failed to acquire a lock because the object is already locked, information on this page identifies the current requestor session that holds the lock. By convention, this page is named LockInfo in standard rules.
As a debugging aid, the standard section rule System-Locks.LockInfo and the standard harness rule Work-.LockInfo can present information from that page to an application user. The LockInfo page contains these properties:
pxExpireDateTime
pxLockHandle
pxOwnerID
pxUpdateOperator
pxCreateDateTime
Releasing locks:
A requestor can only release locks held by its own session, or by another requestor session that has the same Operator ID.
A Commit method releases all the locks held by a requestor Thread that were acquired with the ReleaseOnCommit box checked when the object was opened.
When a user signs off, any locks held by that requestor are released.
Caution in contrast, locks are not released when a user closes a browser session by clicking the Windows close box (rather than by logging out). The locks may be needed by another Thread of the same operator, or by another operator or process. Encourage users to log off through a button or link rather than closing the window.
A Process Commander requestor can lock an open instance if all of the following are true:
The instance belongs to a concrete class that has Allow Locking? checked in the class rule and
The instance has ever been saved and committed to the PegaRULES database.
The requestor has an access role that conveys the privilege needed.
Properties identified on the Locking tab of the Class rule form together define the lock identity. (If the Locking tab contains no property names, the properties that form a lock definition are the same as those that form the external key, on the Database tab.) All classes in one class group (which corresponds to one database table) have the same properties in the lock definition.
To view locks held by your own requestor session, select Designer Studio > Process and Rules > Tools > Work Admin > My Locks.
To view all locks held by any requestor, select Designer Studio > Process and Rules > Tools > Work Admin > All Locks and then drill down to identify the details of the locked object. Hold the mouse pointer over a row of the drill-down detail to identify the Operator ID of the requestor holding the lock.
These two reports present instances of the System-Locks class, corresponding to the pr_sys_locks table of the PegaRULES database.
Locks are acquired by activities, using one of three methods — Obj-Open, Obj-Open-by-Handle, and Obj-Refresh-and-Lock. Optionally, each of these methods can store detailed results in a page of class System-Locks. If a method failed to acquire a lock because the object is already locked, information on this page identifies the current requestor session that holds the lock. By convention, this page is named LockInfo in standard rules.
As a debugging aid, the standard section rule System-Locks.LockInfo and the standard harness rule Work-.LockInfo can present information from that page to an application user. The LockInfo page contains these properties:
pxExpireDateTime
pxLockHandle
pxOwnerID
pxUpdateOperator
pxCreateDateTime
Releasing locks:
A requestor can only release locks held by its own session, or by another requestor session that has the same Operator ID.
A Commit method releases all the locks held by a requestor Thread that were acquired with the ReleaseOnCommit box checked when the object was opened.
When a user signs off, any locks held by that requestor are released.
Caution in contrast, locks are not released when a user closes a browser session by clicking the Windows close box (rather than by logging out). The locks may be needed by another Thread of the same operator, or by another operator or process. Encourage users to log off through a button or link rather than closing the window.