Job should start if two other jobs are successfull

Follow

0

Jonas Seemann

• August 07, 2019 07:20

Hi,

we have a job (Export to CSV) which is dependend on two other jobs. If these two other jobs succeed, the export to csv should start.

However, its behaviour seems random and not logically. If one job is successful the export already starts, although the other job is still running. 

Is this the designated behaviour or is this a bug? 

 

Thanks and BR,

Jonas

• Comment actions Permalink

  Official comment

  

  Niklas Schmidtmer

  • August 07, 2019 07:25

  Hi Jonas,

   

  are you using an atomic schedule for the export job? I posted an example of how atomic schedules work when we introduced them. What you describe sounds like it may not be atomic and you are seeing the described behavior. If that is the case, could you please try making the schedule atomic?

   

  Best

   

  Niklas

• 0

  Comment actions Permalink

  

  Jonas Seemann

  • August 07, 2019 13:09

  Hi Niklas,

  thank you for your response. I changed it to atomic and we will see tomorrow if it worked.

  Thanks and BR,
  Jonas

• 0

  Comment actions Permalink

  

  Jonas Seemann

  • August 08, 2019 07:01

  Hi Niklas,

  thanks for your help. This is the desired behaviour.

  So if I understand you correctly:
  Without atomic, the dependend job starts if one of the jobs is successful.

  With atomic, the dependend job starts if both jobs are successful.

  BR,
  Jonas

   

• 1

  Comment actions Permalink

  

  Niklas Schmidtmer

  • August 12, 2019 07:49

  Hi Jonas,

   

  with both behaviours, the dependent job starts when both parent jobs succeeded. The difference is in the way the status of the parent jobs is tracked.

  As long as the parent jobs always finish with the status SUCCESS, there is no difference between atomic/non-atomic (both parent jobs need to run). Let's consider this example:

  1. Monday: Parent 1 SUCCESS
  2. Monday: Parent 2 SUCCESS
  3. Tuesday: Parent 1 FAILED
  4. Tuesday: Parent 2 SUCCESS

  The non-atomic behavior would now start the dependent job on Tuesday, as it tracked successful runs of both parent jobs. However, those successful runs might fit together semantically, as they were on different days. Atomic fixes this problem by always considering the last executions (so the ones on Tuesday) and would therefore not start the dependent job.

   

  I think the atomic behavior is more intuitive and probably what most users would intuitively expect, so it's probably best to make it a habit using atomic schedules by default. We are also considering changing the defaults (and rename the options) in the product to better match the user's expectations, as I agree that the current way things are named is not intuitive.

   

  Best

   

  Niklas

• 0

  Comment actions Permalink

  

  Jonas Seemann

  • September 17, 2019 09:18

  Hi Niklas,

  I am still not sure if the desired behavior is correct. We had the following situations today:

  The dependent job should start if both parent jobs are successfull in the morning. This is what happened:

  1. Job 1 started at 06.00, finished at 06.10
  2. Dependent Job started, finished some seconds later
  3. Job 2 started at 6.30, finished at 6:32
  4. Dependent Job did not start

  As your explanation the schedule should be like this

  1. Job 1 starts, finishes successfully
  2. Depending job does not start, since job 2 has not started and not finished successfully
  3. Job 2 starts, finishes successfully
  4. Depending job starts

  We scheduled the depending job as Atomic.

  Can you tell me what is wrong?

  Thanks and BR,

  Jonas

• 0

  Comment actions Permalink

  

  Niklas Schmidtmer

  • September 20, 2019 07:37

  Hi Jonas,

  most likely the dependent job considered the previous execution of job 2 together with the latest execution of job 1 to fulfill the condition. To reset the condition (so that it will consider both parent jobs as not executed yet) can be done via SYSADMIN.resetAtomicSchedule.

   

  Best

   

  Niklas

Please sign in to leave a comment.