Lock Handling in Case Hierarchy

In this article, I will elaborate on how the Pega lock mechanism operates within the context of case hierarchy. To grasp the fundamentals of the lock mechanism, please refer to Understanding the Lock Mechanism in Pega

• Inheritance of Locking Strategy

The locking strategy of a child case type is inherited from its parent case type. For instance, if the parent case is set to utilize Pessimistic locking, the child case will also adopt Pessimistic locking. Using different locking strategies between parent and child cases is not feasible.

• Default Locking

Let's begin with Default Locking. When a user locks a child case, the parent case is automatically locked by the same user. This occurs seamlessly in the background, without the user explicitly locking the parent case. Two records are inserted into the PR_SYS_LOCKS table, as depicted below.

When attempting to open an assignment for a child case, if its parent case is already locked by another user, you will encounter an error message.

As a result, the parent case and child case are closely linked, and any operation on the child case necessitates a lock on both cases. This connection is crucial because the parent case maintains status information for its child case, such as "pxCoveredCount" or "pxCoveredCountOpen," and these properties must be consistently updated for each modification to the child case. For instance, if the child case is resolved, "pxCoveredCountOpen" must be decremented; otherwise, the program won't function correctly.

Now, what about the reverse scenario? If someone locks the parent case, is it possible to independently obtain a lock on its child case? Well, from a table perspective, when performing a lock on the parent case, a single record is inserted for the parent case only, as illustrated below. The system does not insert a record for the child case.

Contrary to expectations, if you attempt to open an assignment for the child case while its parent case is locked by another user, you will still encounter the same error message.

This is due to the fact that even though a lock on the child case is not maintained in the database, when attempting to open an assignment from the portal screen, the system activates an out-of-the-box Process API called "WorkLock." In steps 12-15 (refer to the screenshot below), it still attempts to acquire a lock on the parent case.

With that being said, if you execute your own activity to update a child case without utilizing WorkLock, it is indeed possible. For instance, you can create a REST service through which an external system can effectively update the child case even when its parent case is locked.

At this point, it's clear that if either the parent or child case is locked by someone else, you won't be able to acquire a lock on either case from the screen.

You might question why, given that the parent case and child case are distinct objects, we can't work on each case independently. There's a setting that allows for this. Navigate to the case type locking settings of the child case type. You will encounter a checkbox labeled "Allow other users to access the parent case when the child case is opened." This setting is specific to each child case type, so if you have multiple child case types, you can configure it differently for each one.

By default, this checkbox is turned off and is only accessible when the parent case is configured to use Pessimistic Locking. Enabling this checkbox ensures that when you open an assignment for the child case, the system only inserts a record for the child case into the PR_SYS_LOCKS table. No record is inserted for its parent case.

In this way, you can operate on the parent case while someone else locks its child case. However, if the parent case is locked by another user, how does it manage to keep essential properties related to its child cases (e.g., "pxCoveredCountOpen") synchronized? Does it attempt to update later if it initially fails? The answer is, if the parent case is locked by someone else, you can't resolve the child case. This is because the Work-.Resolve is triggered and still requires a lock on its parent case. While any preceding steps before resolution can be executed independently, the final step cannot.

Enabling this checkbox allows you to work independently on the child case while someone else locks its parent case. However, it's important to note that if you configure the parent case to resolve open child cases upon completion (as shown in the screenshot below), the final step of the parent case will require the child case to be unlocked, as the system attempts to resolve both cases.

If another user has a lock on the child case, and you attempt to resolve its parent case, you will encounter the following error.

• Optimistic Locking

If you configure the parent case to use Optimistic Locking, its child case will also utilize Optimistic Locking. In this scenario, User A can work on the parent case while User B is simultaneously working on its child case independently. Optimistic Locking still utilizes the PR_SYS_LOCKS table, but unlike Pessimistic Locking, it swiftly inserts and deletes a record (at the millisecond level) when the Save or Submit button is pressed. The likelihood of collision is minimal.

Happy Learning :) :)