Developers have setup a parent/child work object relationship. As per business requirement multiple users can access the same child work object. To achieve this functionality we set the Optimistic locking in the child work object (modified pyDefault case type advance tab as shown below). However, on the case designer it still shows as default locking. When the same child work object is accessed by different users or same users in different requestor sessions (like in different browsers or using different machines) a lock error is observed.
"The case is already locked...."
STEPS TO REPRODUCE
A software use or operation error: Child cases always take their locking schema from their parent.
Child cases always take their locking scheme from their parent. As the locking schema for the parent case was not changed from the default, the child cases were also using the default locking schema. This is explained on the Locking section of the Advanced tab of the Case Type rule: "Note: This locking schema will be used when the case is instantiated as top case. If instantiated under a parent case, it will inherit the parent's locking schema."
You can set a locking strategy for a case type to control how cases are accessed in your application. By using locking strategies, you reduce the risk of lost updates to a case by concurrently working users.