Announcement Announcement Module
No announcement yet.
Customize step restart behavior Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Customize step restart behavior

    Imagine the following use case: my job is composed of three steps : A then B then C, and A is marked as allow-start-if-complete. This means that if B or C fails and the job is restarted, A will be re-executed (despite being COMPLETED).

    What I want to do is to tell A that it shouldn't be executed during a restart (! allow-start-if-complete), if B has been executed successfully during the first execution of the job. So if C fails, then when restarted only C should be executed. So if the waypoint "B" has been reached, A don't need to be re-executed in case of a batch restart.

    I see several solutions here:

    #1: Add logic inside the steps and in the context to keep track of the last step executed. Then when a step if executed, it will check this information to see if it can be executed (so A knows that it can only be executed if B has not been executed).
    #2: Implement A, B as a first job, and C as a second job, and compose them into a third job. When B completed, the first job will be marked as COMPLETED and A won't be started.

    I currently use solution #2, to avoid adding complexity in the flow of the job. But then Spring Batch meta data's (jobExecutions, jobInstances, ...) are more complex as I use theses meta-jobs. And I'm afraid of solution #1 because for more complex jobs (in my case, 12 steps with 4 different waypoints every 3 steps).

    Does someone have an idea on how to do this in a cleaner way ? (my steps are simple tasklets, not chunk-oriented tasklets

  • #2
    Why not start off with a decision step that determines the state of the job (is it a rerun, etc) and handles the logic from there?


    • #3
      I implemented the decision step with a JobExecutionDecider, which determine which step to go next according to the last waypoint reached (written in the job context). Instead of returning a job status (FAILED, COMPLETED, ...) it returns strings which are the name of the steps to go, and in the decider xml I map a stepname to a stepname (not very nice ) instead of arbitrarily associating a status to a step:

       <decision id="decision" decider="someDecider">
           <next on="stepA" to="stepA"/>
           <next on="stepB" to="stepB"/>
      I'm not really happy with this solution (xml config of the job is not very clear) but at least the jobs meta-datas are kept simple (as opposed to solution #2 in my first post).