Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • The Lock Instruction is used to specify one or more job nodes for mutual exclusion, to prevent 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 either used exclusively or 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.
  • A single Lock Instruction can hold any number of Resource Locks and can span any number of jobs and other workflow instructions.
  • Jobs that are waiting to acquire a Resource Lock do not consume resources such as CPU. Orders that are waiting 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 to have failed. In this situation the following applies:
    • If error handling is applied inside a Lock Instruction, for example by use of a Try/Catch Instruction or Retry Instruction then a temporarily failed order can continue.
    • If no error handling is applied inside a Lock Instruction then the order is moved to the begin of the outmost Lock Instruction and is put to the FAILED state to prevent the order form permanently blocking Resource Locks.
    • Users who wish orders to remain with a failing job or other instruction and to continue to blocking Resource Locks can apply the JS7 - Options 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 blocking Resource Locks for any length of time through 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 Resource Locks from being blocked for a longer time.
  • Changes
    • Jira
      serverSOS JIRA
      columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
      serverId6dc67751-9d67-34cd-985b-194a8cdc9602
      keyJS-1952

...

  • If error handling is applied inside a Lock Instruction, for example by use of a Try/Catch Instruction or Retry Instruction then a temporarily failed order can continue.
  • If no error handling is applied inside a Lock Instruction then the order is moved to the begin of the outmost Lock Instruction and is put to the FAILED state to prevent the order form permanently blocking Resource Locks.
  • Users who wish orders to remain with a failing job or other instruction and to continue to blocking Resource Locks can apply the JS7 - Options Instruction.

...