Java Reference
In-Depth Information
Stopping a Job
A job can stop for a number of reasons, each of which has its own affect on what happens next. It can
run to completion naturally (as all the examples have up to this point). You can programmatically stop
the execution of a job during processing for some reason. You can stop a job externally (say, someone
realizes something is wrong, and they need to stop the job to fix it). And of course, although you may
never admit it, errors can occur that cause a job to stop execution. This section looks at how each of
these scenarios plays out using Spring Batch and your options for what to do when each occurs. Let's
begin with the most basic: a job running to its natural completion.
The Natural End
Up to this point, all of your jobs have run to their natural completion. That is, each job has run all of its
steps until they returned a
COMPLETED
status and the job itself returned an exit code of
COMPLETED
. What
does this mean for a job?
As you've seen, a job can't be executed with the same parameter values more than once
successfully. This is the
successfully
part of that statement. When a job has been run to the
COMPLETED
exit
code, a new JobInstance can't be created using the same JobParameters again. This is important to note
because it dictates how you execute jobs. You've used the
JobParametersIncrementer
to increment
parameters based on their run, which is a good idea, especially in jobs that are run based on a schedule
of some kind. For example, if you have a job that is run daily, developing a
JobParametersIncrementer
implementation that increments a timestamp as a parameter makes sense. That way, each time the job
is executed via the schedule, you use the
-next
flag to increment the job accordingly. If anything
occurred that caused the job to not run to its natural completion, you could execute the job without the
-next
flag, providing the same parameters (you see how to restart jobs later in this chapter).
Not all jobs execute to their natural ending every time. There are situations when you want to stop a
job based on something that happens during processing (an integrity check at the end of a step fails, for
example). In cases like this, you want to stop the job programmatically. The next section goes over this
technique.
Programmatic Ending
Batch processing requires a series of checks and balances to be effective. When you're dealing with large
amounts of data, you need to be able to validate what is happening as things are processing. It's one
thing for a user to update their profile with the wrong address on a web application. That affects one
user. However, what if your job is to import a file containing 1 million records, and the import step
completes after importing only 10,000? Something is wrong, and you need to fix it before the job goes
any further. This section looks at how to stop a job programmatically. First you look at a more real-world
example of using the
<stop>
tag introduced in Chapter 4; you join its use with some new attributes in
order to restart the job. You also look at how to set a flag to end a job.
Using the <stop> Tag
To begin, let's look at constructing a job that is configured to stop using the <stop> tag and how where to
restart is addressed. Let's create a three-step job to process a file:
1.
Import a simple transaction file (
transaction.csv
). Each transaction consists
of an account number, a timestamp, and an amount (positive is a credit,
