Can you please clarify the below point that mentioned in CLSA course about as advantage of using subcase parallelism .
Async Comm: A spun-off subcase that is immune from its parent’s locking strategy can call the Queue-For-Agent to invoke an Activity that invokes a Connector. A Standard Agent Batch Requestor can then attempt and re-attempt the connection in parallel to the parent case with no concern whether the parent case is locked. With the same-case approach, the Standard Agent must wait for the case lock to be released.
The point is that if a subcase is created for the purpose of completing the Async communication, and configured to be locked independently of the parent, it would be the queued object which the agent would lock in order to complete its operation. There would be no lock contention if a simultaneous operation was being performed on the parent case.
There is no locking difference between batch and browser requestor. They both require a lock to update a case. In this example, the subcase is queued for the agent to act upon. With independant locking, the agent only needs to lock the subcase.
Your last statement needs clarification, as the agent only needs to lock the case which is queued. It would not be a good design to update the parent case through the agent of the child case, as this would not solve the original problem of locking which the design was originally meant to solve. You could call the update case infrastructure to update the parent case from the child case either from the smart shape or an activity later on in the subcase process perhaps. You may run into problems if you do not isolate both locking operations (agent locking the subcase, locking the parent case when updating the parent from the subcase).