Bug 5780 - Spec should clarify StepExecution values passed to Decider on a restart
Spec should clarify StepExecution values passed to Decider on a restart
Status: NEW
Product: jbatch
Classification: Unclassified
Component: SPEC
1
All All
: P5 normal
: ---
Assigned To: ScottKurz
1.0_mr_pending
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-12 02:54 UTC by ScottKurz
Modified: 2014-02-13 22:47 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2014-02-12 02:54:47 UTC
See recent ML discussion:

https://java.net/projects/jbatch/lists/public/archive/2014-02/message/5
Comment 1 ScottKurz 2014-02-13 22:47:51 UTC
Pulled out Section 10.8 description of rules involved in restart processing and broke out into an overview section (10.8.3) followed by a slight rewrite of the original 10.8 (now in 10.8.4).

I think the overview should make it much clearer what the details are really referring to.   I also think I was able to make the language a bit more precise in a couple places.  

Let me also note that this update isn't trying to resolve a spec ambiguity..it's just trying to simply spell out one single spec interpretation and not leave as much for the reader to figure out what's being described.  

One more note:  the formatting is awful.  Maybe just wait for the new PDF which I plan to send out tomorrow (2/14).

------------------------------------------------------------------------------


10.8.3	Execution Sequence on Restart – Overview

On the initial execution of a JobInstance, the sequence of execution is essentially:
 1.	Start at initial execution element
 2.	Execute the current execution element
 3.	Either:
  a.	 Transition to next execution element (and go to step 2. above)    OR
  b.	 Terminate execution

On a restart, i.e. a subsequent   execution of a JobInstance, the sequence of execution is similar, but the batch implementation must, in addition, determine which steps it does and does not need to re-execute.
So on a restart, the sequence of execution looks like:
 1.	Start at restart position 
 2.	Decide whether or not to execute (or re-execute) the current execution element 
 3.	Either:
  a.	  Transition to next execution element (and go to step 2. above)    OR
  b.	  Terminate execution

So it follows that for restart we need:  a definition of where in the job definition to begin;  rules for deciding whether or not to execute the current execution element;  and rules for performing transitioning, especially taking into account that all steps relevant to transitioning may not have execute on this (restart) execution.      These rules are provided below.

10.8.4	Execution Sequence on Restart – Detailed Rules

Upon restart, the job is processed as follows:

 1.	Substitutions are processed.

 2.	Start by setting the current position to the restart position.  The restart position is either: 
   a.	the execution element identified by the <stop> element’s “restart” attribute if that is how the previous execution ended; else

   b.	the initial execution element determined the same as upon initial job start, as described in section 8.2.5 Step Sequence;

 3.	Determine if the current execution element should re-execute:
   a.	If the current execution element is a COMPLETED step that specifies allow-restart-if-complete=false, then transition based on the exit status for this step from the previous completed execution.    If the transition is a ‘next’ transition, then repeat step 3 here with the value of ‘next’ as the new, “current” execution element.   Or, if the transition is a terminating transition such as end, stop, or fail, then terminate the restart execution accordingly.

   b.	If the current execution element is a COMPLETED step that specifies allow-restart-if-complete=true, then re-run the step and transition based on the new exit status from the new step execution.    As above, either repeat step 3 with the ‘next’ execution element or terminate the new execution as the transition element 

   c.	If the current execution element is a STOPPED or FAILED step then restart the step and transition based on the exit status from the new step execution. 
Note if the step is a partitioned step, only the partitions that did not complete previously are restarted.  This behavior may be overridden through the PartitionPlan, as specified in section 10.9.4 PartitionPlan.

   d.	If the current execution element is a decision, execute the decision (i.e. execute the Decider) unconditionally.    The Decider’s “decide” method is passed a StepExecution array  as a parameter.    This array will be populated with the most-recently completed StepExecution(s) for each corresponding step.    E.g. some StepExecution(s) may derive from previous job executions and some from the current restart (execution).    A single decision following a split could even have a mix of old, new StepExecution(s) in the same array. 

   e.	If the current  execution element is a flow, transition to the first execution element in the flow and perform step 3 with this as the current element.   When restart processing of the flow has completed, then follow the same rules which apply during the original execution (see section 8.9) to transition at the flow level to the next execution element, and repeat step 3 with that element as the current element.
Note the same rules regarding transitioning within a flow during an original execution apply during restart processing as well.

   f.	If the current execution element is a split, proceed in parallel for each flow in the split.  For each flow, repeat step 3 with the flow element as the current element.   When all flows in the split have been processed, follow the split's transition to the next execution element and repeat step 3 with that element as the current element.