Java Reference
In-Depth Information
Job
JobInstance
JobExecution
Figure 4-3. The relationship between a Job , JobInstance , and JobExecution
When a batch job is run, an org.springframework.batch.core.JobInstance is created. A JobInstance
represents a logical run of the job and is identified by the job name and the parameters passed to the job
for this run. A run of the job is different than an attempt at executing the job. If you have a job that is
expected to run daily, you would have it configured once in your XML (defining the blueprint). Each day
you would have a new run or JobInstance because you pass a new set of parameters into the job (one of
which is the date). Each JobInstance would be considered complete when it has an attempt or
JobExecution that has successfully completed.
Note A JobInstance can only be executed once to a successful completion. Because a JobInstance is
identified by the job name and parameters passed in, this means you can only run a job once with the same
parameters.
You're probably wondering how Spring Batch knows the state of a JobInstance from attempt to
attempt. In Chapter 2, you took a look at the job repository, and in it there was a batch_job_instance
table. This table is the base from which all other tables are derived. It's the batch_job_instance and
batch_job_params that identify a JobInstance (the batch_job_instance.job_key is actually a hash of the
name and parameters).
An is an actual attempt to run the job. If a job runs from start to finish the first time, there is only
one JobExecution related to a given JobInstance . If a job ends in an error state after the first run, a new
JobExecution is created each time an attempt is made to run the JobInstance (by passing in the same
parameters to the same job). For each JobExecution that Spring Batch creates for your job, a record in
the batch_job_execution table is created. As the JobExecution executes, its state is maintained in the
batch_job_execution_context as well. This allows Spring Batch to restart a job at the correct point if an
error occurs.
Configuring a Job
Enough about theory. Let's get into some code. This section digs into the various ways to configure a job.
As mentioned in Chapter 2, as with all of Spring, Spring Batch configurations are done via XML. With
that in mind, one of the very welcome features added to Spring Batch 2 was the addition of a batch XSD
to make configuration of batch jobs more concise.
Note A good best practice is to configure each job in its own XML file named after the name of the job.
 
Search WWH ::




Custom Search