General Description

Isolation-Groups introduce a tool to avoid Workflows running in parallel, and instead create a queue of executions. This keeps Workflows from altering the same resource at the same time, which can cause conflicts and inconsistencies.

Create Isolation-Groups

Users can add Workflows to one or multiple Isolation-Groups using dedicated tags. They are entered into the "Keywords" field of the Meta Information of Workflows.

 These tags need to have a specific structure: !isolation:<group-name>

A Workflow with the tags !isolation:testgroup1 and !isolation:testgroup2 would be assigned to Isolation-Groups testgroup1 and testgroup2.

How This Works

Workflows with the same Isolation-Group tag are assured to never be executed in parallel. While a job execution is already running in an Isolation-Group, all subsequent executions in this group will be queued in the order of their arrival. The same goes for multiple executions of the same Workflow, when it has a Isolation-Group tag. It also works for Workflows that were started via Micro-service, Production Line or Scheduler.

Scheduling Strategy

Isolation-Groups have a specific scheduling strategy. They strive for max throughput of jobs over fairness. So while items in the queue are taken in insertion order, items inside the queue can jump forward, if they can run right now.

Example:

• Job1 (!isolation:G1)
• Job2 (!isolation:G1, !isolation:G2)
• Job3 (!isolation:G2) 

These jobs are submitted roughly at the same time in Job1, Job2, Job3 order. We assume that Job1 and Job3 are long runners. In this case, Job1 and Job3 will run immediately. Job2 has to wait, even though it has been submitted before Job3. That's because Job2 is in both group 1 and 2, while Job3 is only in group 2. Job2 can wait for whichever Job finishes first.