Java Reference
In-Depth Information
}
@AfterStep
public ExitStatus afterStep(StepExecution execution) {
return execution.getExitStatus();
}
}
With no other configuration changes from the previous runs, when you execute
transactionJob
, it
throws a
ParseException
after it reads the record 510 of the transaction file. After this exception is
thrown, Spring Batch considers the step and job failed. If you look at the job execution in Spring Batch
Admin and click the FAILED status of
step1
, you're shown statistics about the job as it ran as well as the
exception that caused the failure. Figure 6-11 shows the result of this execution.
Figure 6-11.
A failed job
There is a big difference between the examples of stopping via StepExecution and stopping the job
with an exception. That difference is the state in which the job is left. In the StepExecution example, the
job was stopped after a step is complete in the
STOPPED
ExitStatus
. In the exception case, the step didn't
finish. In fact, it was part way through the step when the exception was thrown. Because of this, the step
and job are labeled with the
ExitStatus
FAILED
.
When a step is identified as
FAILED
, Spring Batch doesn't start the step over from the beginning.
Instead, Spring Batch is smart enough to remember what chunk you were on when the exception was
thrown. When you restart the job, Spring Batch picks up at the chunk it left off on. As an example, let's
say the job is processing chunk 5 of 10, with each chunk consisting of 5 items. An exception is thrown on
the fourth item of the second chunk. Items 1-4 of the current chunk are rolled back, and when you
restart, Spring Batch skips chunks one and two.
Although Spring Batch's default method of handling an exception is to stop the job in the failed
status, there are other options at your disposal. Because most of those depend on input/output-specific
scenarios, the next few chapters cover them together with I/O.
