diff --git a/docs/src/site/docbook/reference/core.xml b/docs/src/site/docbook/reference/core.xml
index edabf423b..4f84173ce 100644
--- a/docs/src/site/docbook/reference/core.xml
+++ b/docs/src/site/docbook/reference/core.xml
@@ -745,11 +745,156 @@
executionContext.putLong(getKey(LINES_READ_COUNT), reader.getPosition());
- The call above will store the current number of lines read into
- the ExecutionContext. It should be made just before the framework
- commits. Being notified before a commit requires one of the various
- StepListeners, or an ItemStream, which are
- discussed in more detail later in this guide. When the
+ Using the EndOfDay example from the Job Stereotypes section as an
+ example, assume there's one step: 'loadData', that loads a file into the
+ database. After the first failed run, the meta data tables would look
+ like the following:
+
+
+ BATCH_JOB_INSTANCE
+
+
+
+
+ JOB_INSTANCE_ID
+
+ JOB_NAME
+
+
+
+ 1
+
+ EndOfDayJob
+
+
+
+
+ BATCH_JOB_PARAMS
+
+
+
+
+ JOB_INSTANCE_ID
+
+ TYPE_CD
+
+ KEY_NAME
+
+ DATE_VAL
+
+
+
+ 1
+
+ DATE
+
+ schedule.Date
+
+ 2008-01-01 00:00:00
+
+
+
+
+ BATCH_JOB_EXECUTION
+
+
+
+
+ JOB_EXECUTION_ID
+
+ JOB_INSTANCE_ID
+
+ START_TIME
+
+ END_TIME
+
+ STATUS
+
+
+
+ 1
+
+ 1
+
+ 2008-01-01 21:00:23.571
+
+ 2008-01-01 21:30:17.132
+
+ FAILED
+
+
+
+
+ BATCH_STEP_EXECUTION
+
+
+
+
+ STEP_EXECUTION_ID
+
+ JOB_EXECUTION_ID
+
+ STEP_NAME
+
+ START_TIME
+
+ END_TIME
+
+ STATUS
+
+
+
+ 1
+
+ 1
+
+ loadDate
+
+ 2008-01-01 21:00:23.571
+
+ 2008-01-01 21:30:17.132
+
+ FAILED
+
+
+
+
+ BATCH_EXECUTION_CONTEXT
+
+
+
+
+ EXECUTION_ID
+
+ TYPE_CD
+
+ KEY_NAME
+
+ LONG_VAL
+
+
+
+ 1
+
+ LONG
+
+ piece.count
+
+ 40321
+
+
+
+
In this case, the Step ran for 30
+ minutes and processed 40,321 'pieces', which would represent lines in a
+ file in this scenario. This value will be updated just before each
+ commit by the framework, and can contain multiple rows corresponding to
+ entries within the ExecutionContext. Being
+ notified before a commit requires one of the various StepListeners, or
+ an ItemStream, which are discussed in more detail
+ later in this guide. As with the previous example, it is assumed that
+ the Job is restarted the next day. When it is restarted, the values from
+ the ExecutionContext of the last run are
+ reconstituted from the database, and when the
ItemReader is opened, it can check to see if it
has any stored state in the context, and initialize itself from
there:
@@ -767,14 +912,17 @@
}
}
- The ExecutionContext can also be used for
- startistics that need to be persisted about the run itself. For example,
- if a flat file contains orders for processing that exist across multiple
- lines, it may be necessary to store how many orders have been processed
- (which is much different from than the number of lines read) so that an
- email can be sent at the end of the Step with the
- total orders processed in the body. The framework handles storing this
- for the developer, in order to correctly scope it with an individual
+ In this case, after the above code is executed, the current line
+ will be 40,322, allowing the Step to start again
+ from where it left off. The ExecutionContext can
+ also be used for statistics that need to be persisted about the run
+ itself. For example, if a flat file contains orders for processing that
+ exist across multiple lines, it may be necessary to store how many
+ orders have been processed (which is much different from than the number
+ of lines read) so that an email can be sent at the end of the
+ Step with the total orders processed in the body.
+ The framework handles storing this for the developer, in order to
+ correctly scope it with an individual
JobInstance. It can be very difficult to know
whether an existing ExecutionContext should be
used or not. For example, using the 'EndOfDay' example from above, when