Let us assume that the dependencies between the components in the repository are as shown in the next figure.
Components A, B, and C depend on components D and E, which depend on component F, G, and H.
All components to be changed by the current operation are locked with EXCLUSIVE lock, and the components that should not be changed during the operation by other operations, are locked with SHARED lock.
The system puts and releases all locks in one step, not sequentially.
Components with:
· No relation to this deployment operation are shown in grey
· EXCLUSIVE lock are shown in red
· SHARED lock are shown in yellow
In the case with single deployment batch that contains the applications A, E, and F:
· A, E, and F are going to be locked with EXCLUSIVE lock
· D, G, and H are locked with SHARED lock
In the case with two deployment batches – one with component D and one with component E:
● D and E are locked with EXCLUSIVE lock.
● F and H are locked with one SHARED lock, and G – with two.
With one undeployment batch (A, E and F) with IfDependingStop undeployment strategy:
● A, E, and F are locked with EXCLUSIVE lock
● B, C, and D are locked with SHARED lock
With two undeployment batches – one with D and one with E and SkipDepending undeployment strategy:
● D and E are locked with EXCLUSIVE lock
With two undeployment batches - Batch1{D} and Batch2{E} and UndeployDepending undeployment strategy:
● A, B, and D are locked with EXCLUSIVE locks
Note: Only Batch1{D} succeeds. Batch2{E} fails because it needs to set a lock on B, which is already locked by Batch1{D}.