RestartabilityOne key issue when executing a batch job concerns the behavior of
- a Job when it is restarted? The launching of a
+ a Job when it is restarted. The launching of a
Job is considered to be a 'restart' if a
JobExecution already exists for the particular
JobInstance. Ideally, all jobs should be able to
@@ -214,7 +214,7 @@ catch (JobRestartException e) {
of simple mandatory and optional parameters, and for more complex
constraints you can implement the interface yourself. The configuration
of a validator is supported through the XML namespace through a child
- element of the job, e.g>:
+ element of the job, e.g:
@@ -265,7 +265,7 @@ catch (JobRestartException e) {
length of the long VARCHAR columns in the sample schema scripts
- used to store things like exit code descriptions. If you don't modify the schema and you don't use multi-bye characters you shouldn't need to change it.
+ used to store things like exit code descriptions. If you don't modify the schema and you don't use multi-byte characters you shouldn't need to change it.
Transaction Configuration for the JobRepository
@@ -1044,7 +1044,7 @@ jobOperator.stop(executions.iterator().next()); ]]>Aborting a JobA job execution which is FAILED can be
- restartsed (if the Job is restartable). A job execution whose status is
+ restarted (if the Job is restartable). A job execution whose status is
ABORTED will not be restarted by the framework.
The ABORTED status is also used in step
executions to mark them as skippable in a restarted job execution: if a