...

• The Lock Instruction is used to specify a number of job nodes for mutual exclusion to prevent such jobs from being executed in parallel either in the same workflow or in different workflows.
• Mutual exclusion is based on Resource Locks, i.e. semaphores, that can be used either exclusively or that can be shared within the limits of their capacity.
  • Exclusive Resource Lock: only one Lock Instruction can hold the Resource Lock at any given time. Any further Lock Instructions that try to acquire the same Resource Lock have to wait.
  • Shared Resource Lock: the Resource Lock is assigned a capacity that can be shared by a number of Lock Instructions. Each Lock Instruction carries a weight that counts towards the Resource Lock's capacity.
• Jobs that wait to acquire a Resource Lock do not consume resources such as CPU. Orders that wait for a Resource Lock are in a WAITING state, see JS7 - Order State Transitions.
• If a job within a Lock Instruction fails then the order is considered being failed. In this situation the Resource Lock is still in use by the Lock Instruction.
• Note that Lock Instructions can be nested in a workflow that acquires a number of Resource Locks. This adds complexity to your workflows that should be managed to prevent deadlocks. It is recommended
  • to use the same nesting of Resource Locks for any occurrence in order to avoid deadlocks,
  • not to block
  a number of
  • Resource Locks for a longer time by failed orders if the Resource Locks span across a number of jobs that allow orders to remain in a FAILED state. Using Resource Locks for single jobs only or use of the JS7 - Try / Catch Instruction will prevent deadlocks.
• Changes

  • Jira
    server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JS-1952

Feature Video

This video explains how to limit parallel execution of jobs in a workflow.

...