Process Commander has several locking mechanisms:

• You can lock a RuleSet version with passwords, preventing any changes to the rules associated with that RuleSet or version.
• A requestor may acquire temporary exclusive access to an instance, preventing other requestors from updating or deleting it.
• You can lock an application rule (Rule-Application rule type) with a password, preventing others from changing that rule instance until they enter the password.

RuleSet version locking

When a rule belongs to a locked RuleSet version, a lock icon appears at the upper left of the form.

See RuleSet Form — Completing the Security tab and RuleSet Version form — Completing the Security tab.

Securing a RuleSet or RuleSet version is reversible. A password may be require to unlock a locked RuleSet or RuleSet version.

Object locking

A Process Commander requestor can lock an open instance if the instance belongs to a concrete class that has Allow Locking? selected in the class rule and it has ever been saved and committed to the PegaRULES database. Locks are retained until a Commit method occurs.

Object locks are implemented separately from the locking mechanism supplied by the database software (such as Oracle) that supports the PegaRULES database.

To view object locks held by your own requestor session, select View > System > Locks > My Locks.

Testing for locks

To test whether a work object is locked, an activity can call the standard activity Work-.WorkLock, which attempts to lock the work object. If it fails to acquire a lock, the SuccessInfo parameter is negative, indicating that the work object is already locked. The FailureInfo parameter provides additional detail.

To test whether an object (other than a work object) is locked, use one of several methods in the PublicAPI LockManagerInterface.

	soft lock
	About application rules About RuleSet Version rules Concepts — Understanding object locking Commit method Understanding locking and transactions in flow executions

Definitions — L