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.
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.
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.
There is a Property in pr_sys_locks , it hold's the lock expire time: pxexpiredatetime
If User A opens the case, even if you click on the button Save/Submit, it will not automatically increase the time.
If you open the case at 12:00 PM, User A locks in for up to 12:30 only. After that, Lock was released automatically. On the other side, if User B opens the case again, User B locks the case for the next 30 minutes.
In such a case, As soon as expire of the lock, User A should refresh the screen or reopen the case. The case lock should not be auto-extended. If you do not refresh or reopen the case, lock time will not extended.
Note: If you refresh the screen before expiring the lock release, it won't extend the automatically lock time, and if you close the case and re-open the case before expiring the lock, it will again start fresh from 0 to 30.