diff --git a/src/site/docbook/reference/domain.xml b/src/site/docbook/reference/domain.xml
index 366bfa823..48010b1b3 100644
--- a/src/site/docbook/reference/domain.xml
+++ b/src/site/docbook/reference/domain.xml
@@ -107,14 +107,14 @@
namespace abstracts away the need to instantiate it directly. Instead, the
<job> tag can be used:
-
- <job id="footballJob">
- <step id="playerload" next="gameLoad"/>
- <step id="gameLoad" next="playerSummarization"/>
- <step id="playerSummarization"/>
- </job>
+
+
+
+
+
-
+]]>
JobInstance
@@ -133,10 +133,13 @@
Therefore, each JobInstance can have multiple
executions (JobExecution is discussed in more
detail below) and only one JobInstance
- corresponding to a particular Job can be running
- at a given time. The definition of a JobInstance
- has absolutely no bearing on the data the will be loaded. It is entirely
- up to the ItemReader implementation used to
+ corresponding to a particular Job and
+ JobParameters can be running at a given time.
+
+
+ The definition of a JobInstance has
+ absolutely no bearing on the data the will be loaded. It is entirely up
+ to the ItemReader implementation used to
determine how data will be loaded. For example, in the EndOfDay
scenario, there may be a column on the data that indicates the
'effective date' or 'schedule date' to which the data belongs. So, the
@@ -713,7 +716,7 @@
is to put the current number of lines read into the context, and the
framework will do the rest:
- executionContext.putLong(getKey(LINES_READ_COUNT), reader.getPosition());
+
Using the EndOfDay example from the Job Stereotypes section as an
example, assume there's one step: 'loadData', that loads a file into the
@@ -860,7 +863,7 @@
ItemReader is opened, it can check to see if it has
any stored state in the context, and initialize itself from there:
- if (executionContext.containsKey(getKey(LINES_READ_COUNT))) {
+
+ }]]>
In this case, after the above code is executed, the current line
will be 40,322, allowing the Step to start again
@@ -911,12 +914,12 @@
StepExecution. For example, consider the following
code snippet:
-
+
+]]>
As noted in the comment, ecStep will not equal ecJob; they are two
different ExecutionContexts. The one scoped to the
@@ -939,10 +942,10 @@
JobExecution implementations are persisted by
passing them to the repository:
-
- <job-repository id="jobRepository"/>
+
-
+]]>
@@ -952,12 +955,12 @@
launching a Job with a given set of
JobParameters:
- public interface JobLauncher {
+
+]]>
It is expected that implementations will obtain a valid
JobExecution from the
@@ -1033,4 +1036,4 @@
linkend="configureJob" />. More information on configuring a Step can be
found in .
-
+
\ No newline at end of file
diff --git a/src/site/docbook/reference/job.xml b/src/site/docbook/reference/job.xml
index c054d6a2d..97082daaf 100644
--- a/src/site/docbook/reference/job.xml
+++ b/src/site/docbook/reference/job.xml
@@ -73,7 +73,7 @@
JobInstance. Ideally, all jobs should be able to
start up where they left off, but there are scenarios where this is not
possible. It is entirely up to the developer to
- ensure that a new JobInstance is created in this scenario.
+ ensure that a new JobInstance is created in this scenario.
However, Spring Batch does provide some help. If a
Job should never be restarted, but should always
be run as part of a new JobInstance, then the