Hi,

In this post, I will explain how Pega lock mechanism works with case hierarchy. For lock mechanism basics, please see https://support.pega.com/discussion/pega-lock-mechanism.

• Inheritance of locking strategy

Child case type inherits the locking strategy of its parent case type. For example, if parent case is configured to use Pessimistic locking, child case will also use Pessimistic locking. It is not possible to use different locking between parent / child cases.

• Pessimistic locking

Let's start with Pessimistic locking. When child case is locked by a user, its parent case is also locked by the same user. This happens automatically in the background, without user explicitly locking a parent case. Two records are inserted into PR_SYS_LOCKS table, as shown below.

When you try to open an assignment of child case, if its parent case is already locked by someone else, you will see an error message.

Thus, parent case and child case are tightly coupled and performing on child case requires a lock on both cases. This is because parent case holds its child case status, such as "pxCoveredCount" or "pxCoveredCountOpen" and these properties need to be maintained per child case update. For example, if child case is resolved, "pxCoveredCountOpen" must be decremented or program won't work correctly.

Now, how about the other way around? If someone locks parent case, can you obtain a lock on its child case independently? Well, from table perspectives, performing parent case inserts a single record for parent case only, as shown below. System doesn't insert a record for child case.

However, against expectations, if you try to open an assignment of child case while its parent case is locked by someone else, you will still get the same error message.

This is because, although a lock on child case is not held in the database, when you try to open an assignment from portal screen, system triggers an out-of-the-box Process API "WorkLock" and it still tries to obtain a lock on parent case in step 12-15 (see below screenshot).

That said, if you run your own activity to simply update a child case without using WorkLock, you can. For example, you can create REST Service by which external system can successfully update child case while its parent case is locked.

At this point, we've learned that if any of parent or child case is locked by someone else, you can't obtain a lock on either case from screen.

You may wonder, parent case and child case are separate objects and why can't we work on each case independently. There is a setting to enable this. Go to case type locking setting of child case type. You will find a checkbox "Allow other users to access parent case when the child case is opened". This is per child case type. If you have multiple child case types, you can configure it differently per child case type.

This checkbox is off by default, and available only when parent case is configured to use Pessimistic Locking. By turning on this checkbox, when you open an assignment of child case, system only inserts a child case record to PR_SYS_LOCKS table. System doesn't insert a record for its parent case.

This way, you can work on parent case while someone else locks its child case. If parent case is locked by someone else, how does its parent case maintain the important properties about its child cases (i.e. "pxCoveredCountOpen") in sync? Does it retry update later if it fails? The answer is, if its parent case is locked by someone else, you can't resolve the child case (see below error message). This is because Work-.Resolve is triggered and it still requires a lock on its parent case. Any prior steps before resolution can be performed independently, but not the final step.

By turning on this checkbox, you can also independently work on child case while someone else locks its parent case. Be noted, if you configure parent case to resolve open child cases when completion (see below screenshot), parent case's final step will need the child case to be unlocked as system tries to resolve both cases.

If other user has a lock on child case, and if you try to resolve its parent case, you will see below error.

• Optimistic locking

If you configure parent case to use Optimistic locking, its child case will also use Optimistic locking. In this case, user A can work on parent case while user B is working on its child case, independently. Optimistic locking still uses PR_SYS_LOCKS table, but unlike Pessimistic locking, it inserts / deletes a record very quickly (at milliseconds level) when Save or Submit button is hit. There is a very little possibility of collision.

Thanks,