Page History

y_join.zip

Anchor
scope scope

Scope

The Join Orders Job (JobSchedulerJoinOrders) is a JITL Job and is used to join up parallel executing child segments in a Job Chain. It then continues processing with a single Order in a single thread once processing of the parallel threads has been completed. It is used in two Job Chain Patterns - Split and Join and "Y".

...

• See the How To Synchronize Job Execution Across Job Chains article for information about synchronizing using the Sync Job (JobSchedulerSynchronizeJobChains) to synchronize Jobs in different Job Chains and for joining to join up parallel executing child Job Chain segments in JobScheduler versions 1.11.3 and older.
• The Join Orders Job provides a plug-in replacement for the Sync Job (JobSchedulerSynchronizeJobChains) for sync/join operations within a Job Chain. As the Join Orders Job is significantly faster than the Sync Job, users of JobScheduler 1.11.4 or newer wishing to improve performance of the Sync Job can simply replace their Sync Job with the Join Orders Job.

...

The following diagram shows the "Y"-pattern Job Chain used in the example download archive that is linked from this article. Note that the generate and wait Jobs in this example have been included to make the example work and are not required for its operation in "normal" use.

main [label="Order:main_order",fillcolor="green"]
100 [label="generate orders",fillcolor="lightskyblue"]
add [label="Order:main_order_add-order",fillcolor="green"]
150 [label="wait",fillcolor="lightskyblue"]
200 [label="200 job_a",fillcolor="lightskyblue"]
300 [label="300 job_b",fillcolor="lightskyblue"]
join [label="join orders",fillcolor="lightskyblue"]
400 [label="400 job_c",fillcolor="lightskyblue"]
success [label="success",fillcolor="orange"]

main -> 100 
100 -> 150 
150  -> 200 
200 -> join 
add -> 300 
300 -> join 
join -> 400 
400 -> success 

• Note that the generate and wait Jobs in this example have been included to make the example work and are not required for its operation in "normal" use.
• All Jobs in the "Y"-pattern are configured as a single Job Chain.
• The generate and wait Jobs in the example provide a convenient way of making the example work - they would not be required in a 'real' implementationparallel arms of the example are effectively job_a to the Join Orders Job and job_b to the Join Orders Job.  

Download and Configure the Example

...

• In the current example, running the main_order_add-order Order once will cause the number of Orders counted to reach the value set in the required_orders parameter (1210).
  • The Join Orders Job will now process the main_order which will then proceed along the Job Chain - in this example to the Job C with the state 200400.
• The ID of this Order has to follow one of the convention conventions used for other to identify Child Orders - that is, . Here the ID of the parent Order plus an underscore plus a string has been used.
  
  • Note that this string may not contain an underscore character ("_") and therefore the string "add-order" has been used.

Note that Child Orders such as the generated Orders or the manually started main_order_add-order Order in this example will only be recognized as such when they are started after the Parent Order has been started.

...