From f40c4f04ce1728081c0e6a435f095b28de0e0697 Mon Sep 17 00:00:00 2001 From: dsyer Date: Sun, 15 Mar 2009 09:10:45 +0000 Subject: [PATCH] Tweak wording in Job identity section --- src/site/docbook/reference/domain.xml | 49 ++++++++++++++------------- src/site/docbook/reference/job.xml | 2 +- 2 files changed, 27 insertions(+), 24 deletions(-) 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