252 lines
33 KiB
HTML
252 lines
33 KiB
HTML
<html><head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
|
<title>Appendix B. Meta-Data Schema</title><link rel="stylesheet" type="text/css" href="css/manual-multipage.css"><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><link rel="home" href="index.html" title="Spring Batch - Reference Documentation"><link rel="up" href="index.html" title="Spring Batch - Reference Documentation"><link rel="prev" href="listOfReadersAndWriters.html" title="Appendix A. List of ItemReaders and ItemWriters"><link rel="next" href="transactions.html" title="Appendix C. Batch Processing and Transactions"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix B. Meta-Data Schema</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="listOfReadersAndWriters.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="transactions.html">Next</a></td></tr></table><hr></div><div class="appendix"><div class="titlepage"><div><div><h1 class="title"><a name="metaDataSchema" href="#metaDataSchema"></a>Appendix B. Meta-Data Schema</h1></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="metaDataSchemaOverview" href="#metaDataSchemaOverview"></a>B.1 Overview</h2></div></div></div><p>The Spring Batch Meta-Data tables very closely match the Domain
|
|
objects that represent them in Java. For example,
|
|
<code class="classname">JobInstance</code>, <code class="classname">JobExecution</code>,
|
|
<code class="classname">JobParameters</code>, and
|
|
<code class="classname">StepExecution</code> map to BATCH_JOB_INSTANCE,
|
|
BATCH_JOB_EXECUTION, BATCH_JOB_EXECUTION_PARAMS, and BATCH_STEP_EXECUTION,
|
|
respectively. <code class="classname">ExecutionContext</code> maps to both
|
|
BATCH_JOB_EXECUTION_CONTEXT and BATCH_STEP_EXECUTION_CONTEXT. The
|
|
<code class="classname">JobRepository</code> is responsible for saving and storing
|
|
each Java object into its correct table. The following appendix describes
|
|
the meta-data tables in detail, along with many of the design decisions
|
|
that were made when creating them. When viewing the various table creation
|
|
statements below, it is important to realize that the data types used are
|
|
as generic as possible. Spring Batch provides many schemas as examples,
|
|
which all have varying data types due to variations in individual database
|
|
vendors' handling of data types. Below is an ERD model of all 6 tables and
|
|
their relationships to one another:</p><div class="mediaobject" align="center"><img src="images/meta-data-erd.png" align="middle"></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="exampleDDLScripts" href="#exampleDDLScripts"></a>B.1.1 Example DDL Scripts</h3></div></div></div><p>The Spring Batch Core JAR file contains example
|
|
scripts to create the relational tables for a number of database
|
|
platforms (which are in turn auto-detected by the job repository factory
|
|
bean or namespace equivalent). These scripts can be used as is, or
|
|
modified with additional indexes and constraints as desired. The file
|
|
names are in the form <code class="literal">schema-*.sql</code>, where "*" is the
|
|
short name of the target database platform. The scripts are in
|
|
the package <code class="literal">org.springframework.batch.core</code>.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="metaDataVersion" href="#metaDataVersion"></a>B.1.2 Version</h3></div></div></div><p>Many of the database tables discussed in this appendix contain a
|
|
version column. This column is important because Spring Batch employs an
|
|
optimistic locking strategy when dealing with updates to the database.
|
|
This means that each time a record is 'touched' (updated) the value in
|
|
the version column is incremented by one. When the repository goes back
|
|
to try and save the value, if the version number has change it will
|
|
throw <code class="classname">OptimisticLockingFailureException</code>,
|
|
indicating there has been an error with concurrent access. This check is
|
|
necessary since, even though different batch jobs may be running in
|
|
different machines, they are all using the same database tables.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="metaDataIdentity" href="#metaDataIdentity"></a>B.1.3 Identity</h3></div></div></div><p>BATCH_JOB_INSTANCE, BATCH_JOB_EXECUTION, and BATCH_STEP_EXECUTION
|
|
each contain columns ending in _ID. These fields act as primary keys for
|
|
their respective tables. However, they are not database generated keys,
|
|
but rather they are generated by separate sequences. This is necessary
|
|
because after inserting one of the domain objects into the database, the
|
|
key it is given needs to be set on the actual object so that they can be
|
|
uniquely identified in Java. Newer database drivers (Jdbc 3.0 and up)
|
|
support this feature with database generated keys, but rather than
|
|
requiring it, sequences were used. Each variation of the schema will
|
|
contain some form of the following:</p><pre class="programlisting"><span class="hl-keyword">CREATE</span> <span class="hl-keyword">SEQUENCE</span> BATCH_STEP_EXECUTION_SEQ;
|
|
<span class="hl-keyword">CREATE</span> <span class="hl-keyword">SEQUENCE</span> BATCH_JOB_EXECUTION_SEQ;
|
|
<span class="hl-keyword">CREATE</span> <span class="hl-keyword">SEQUENCE</span> BATCH_JOB_SEQ;</pre><p>Many database vendors don't support sequences. In these cases,
|
|
work-arounds are used, such as the following for MySQL:</p><pre class="programlisting"><span class="hl-keyword">CREATE</span> <span class="hl-keyword">TABLE</span> BATCH_STEP_EXECUTION_SEQ (ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>) <span class="hl-keyword">type</span>=InnoDB;
|
|
<span class="hl-keyword">INSERT</span> <span class="hl-keyword">INTO</span> BATCH_STEP_EXECUTION_SEQ <span class="hl-keyword">values</span>(<span class="hl-number">0</span>);
|
|
<span class="hl-keyword">CREATE</span> <span class="hl-keyword">TABLE</span> BATCH_JOB_EXECUTION_SEQ (ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>) <span class="hl-keyword">type</span>=InnoDB;
|
|
<span class="hl-keyword">INSERT</span> <span class="hl-keyword">INTO</span> BATCH_JOB_EXECUTION_SEQ <span class="hl-keyword">values</span>(<span class="hl-number">0</span>);
|
|
<span class="hl-keyword">CREATE</span> <span class="hl-keyword">TABLE</span> BATCH_JOB_SEQ (ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>) <span class="hl-keyword">type</span>=InnoDB;
|
|
<span class="hl-keyword">INSERT</span> <span class="hl-keyword">INTO</span> BATCH_JOB_SEQ <span class="hl-keyword">values</span>(<span class="hl-number">0</span>);</pre><p>In the above case, a table is used in place of each sequence. The
|
|
Spring core class <code class="classname">MySQLMaxValueIncrementer</code> will
|
|
then increment the one column in this sequence in order to give similar
|
|
functionality.</p></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="metaDataBatchJobInstance" href="#metaDataBatchJobInstance"></a>B.2 BATCH_JOB_INSTANCE</h2></div></div></div><p>The BATCH_JOB_INSTANCE table holds all information relevant to a
|
|
<code class="classname">JobInstance</code>, and serves as the top of the overall
|
|
hierarchy. The following generic DDL statement is used to create
|
|
it:</p><pre class="programlisting"><span class="hl-keyword">CREATE</span> <span class="hl-keyword">TABLE</span> BATCH_JOB_INSTANCE (
|
|
JOB_INSTANCE_ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">PRIMARY</span> <span class="hl-keyword">KEY</span> ,
|
|
VERSION <span class="hl-keyword">BIGINT</span>,
|
|
JOB_NAME <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">100</span>) <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span> ,
|
|
JOB_KEY <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">2500</span>)
|
|
);</pre><p>Below are descriptions of each column in the table:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>JOB_INSTANCE_ID: The unique id that will identify the instance,
|
|
which is also the primary key. The value of this column should be
|
|
obtainable by calling the <code class="methodname">getId</code> method on
|
|
<code class="classname">JobInstance</code>.</p></li><li class="listitem"><p>VERSION: See above section.</p></li><li class="listitem"><p>JOB_NAME: Name of the job obtained from the
|
|
<code class="classname">Job</code> object. Because it is required to identify
|
|
the instance, it must not be null.</p></li><li class="listitem"><p>JOB_KEY: A serialization of the
|
|
<code class="classname">JobParameters</code> that uniquely identifies separate
|
|
instances of the same job from one another.
|
|
(<code class="classname">JobInstances</code> with the same job name must have
|
|
different <code class="classname">JobParameters</code>, and thus, different
|
|
JOB_KEY values).</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="metaDataBatchJobParams" href="#metaDataBatchJobParams"></a>B.3 BATCH_JOB_EXECUTION_PARAMS</h2></div></div></div><p>The BATCH_JOB_EXECUTION_PARAMS table holds all information relevant to the
|
|
<code class="classname">JobParameters</code> object. It contains 0 or more
|
|
key/value pairs passed to a <code class="classname">Job</code> and serve as a record of the parameters
|
|
a job was run with. For each parameter that contributes to the generation of a job's identity,
|
|
the IDENTIFYING flag is set to true. It should be noted that the table has been
|
|
denormalized. Rather than creating a separate table for each type, there
|
|
is one table with a column indicating the type:</p><pre class="programlisting"><span class="hl-keyword">CREATE</span> <span class="hl-keyword">TABLE</span> BATCH_JOB_EXECUTION_PARAMS (
|
|
JOB_EXECUTION_ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span> ,
|
|
TYPE_CD <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">6</span>) <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span> ,
|
|
KEY_NAME <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">100</span>) <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span> ,
|
|
STRING_VAL <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">250</span>) ,
|
|
DATE_VAL DATETIME <span class="hl-keyword">DEFAULT</span> <span class="hl-keyword">NULL</span> ,
|
|
LONG_VAL <span class="hl-keyword">BIGINT</span> ,
|
|
DOUBLE_VAL <span class="hl-keyword">DOUBLE</span> <span class="hl-keyword">PRECISION</span> ,
|
|
IDENTIFYING <span class="hl-keyword">CHAR</span>(<span class="hl-number">1</span>) <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span> ,
|
|
<span class="hl-keyword">constraint</span> JOB_EXEC_PARAMS_FK <span class="hl-keyword">foreign</span> <span class="hl-keyword">key</span> (JOB_EXECUTION_ID)
|
|
<span class="hl-keyword">references</span> BATCH_JOB_EXECUTION(JOB_EXECUTION_ID)
|
|
);</pre><p>Below are descriptions for each column:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>JOB_EXECUTION_ID: Foreign Key from the BATCH_JOB_EXECUTION table
|
|
that indicates the job execution the parameter entry belongs to. It
|
|
should be noted that multiple rows (i.e key/value pairs) may exist for
|
|
each execution.</p></li><li class="listitem"><p>TYPE_CD: String representation of the type of value stored,
|
|
which can be either a string, date, long, or double. Because the type
|
|
must be known, it cannot be null.</p></li><li class="listitem"><p>KEY_NAME: The parameter key.</p></li><li class="listitem"><p>STRING_VAL: Parameter value, if the type is string.</p></li><li class="listitem"><p>DATE_VAL: Parameter value, if the type is date.</p></li><li class="listitem"><p>LONG_VAL: Parameter value, if the type is a long.</p></li><li class="listitem"><p>DOUBLE_VAL: Parameter value, if the type is double.</p></li><li class="listitem"><p>IDENTIFYING: Flag indicating if the parameter contributed to the identity of the related <code class="classname">JobInstance</code>.</p></li></ul></div><p>It is worth noting that there is no primary key for this table. This
|
|
is simply because the framework has no use for one, and thus doesn't
|
|
require it. If a user so chooses, one may be added with a database
|
|
generated key, without causing any issues to the framework itself.</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="metaDataBatchJobExecution" href="#metaDataBatchJobExecution"></a>B.4 BATCH_JOB_EXECUTION</h2></div></div></div><p>The BATCH_JOB_EXECUTION table holds all information relevant to the
|
|
<code class="classname">JobExecution</code> object. Every time a
|
|
<code class="classname">Job</code> is run there will always be a new
|
|
<code class="classname">JobExecution</code>, and a new row in this table:</p><pre class="programlisting"><span class="hl-keyword">CREATE</span> <span class="hl-keyword">TABLE</span> BATCH_JOB_EXECUTION (
|
|
JOB_EXECUTION_ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">PRIMARY</span> <span class="hl-keyword">KEY</span> ,
|
|
VERSION <span class="hl-keyword">BIGINT</span>,
|
|
JOB_INSTANCE_ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>,
|
|
CREATE_TIME <span class="hl-keyword">TIMESTAMP</span> <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>,
|
|
START_TIME <span class="hl-keyword">TIMESTAMP</span> <span class="hl-keyword">DEFAULT</span> <span class="hl-keyword">NULL</span>,
|
|
END_TIME <span class="hl-keyword">TIMESTAMP</span> <span class="hl-keyword">DEFAULT</span> <span class="hl-keyword">NULL</span>,
|
|
STATUS <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">10</span>),
|
|
EXIT_CODE <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">20</span>),
|
|
EXIT_MESSAGE <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">2500</span>),
|
|
LAST_UPDATED <span class="hl-keyword">TIMESTAMP</span>,
|
|
JOB_CONFIGURATION_LOCATION <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">2500</span>) <span class="hl-keyword">NULL</span>,
|
|
<span class="hl-keyword">constraint</span> JOB_INSTANCE_EXECUTION_FK <span class="hl-keyword">foreign</span> <span class="hl-keyword">key</span> (JOB_INSTANCE_ID)
|
|
<span class="hl-keyword">references</span> BATCH_JOB_INSTANCE(JOB_INSTANCE_ID)
|
|
) ;</pre><p>Below are descriptions for each column:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>JOB_EXECUTION_ID: Primary key that uniquely identifies this
|
|
execution. The value of this column is obtainable by calling the
|
|
<code class="methodname">getId</code> method of the
|
|
<code class="classname">JobExecution</code> object.</p></li><li class="listitem"><p>VERSION: See above section.</p></li><li class="listitem"><p>JOB_INSTANCE_ID: Foreign key from the BATCH_JOB_INSTANCE table
|
|
indicating the instance to which this execution belongs. There may be
|
|
more than one execution per instance.</p></li><li class="listitem"><p>CREATE_TIME: Timestamp representing the time that the execution
|
|
was created.</p></li><li class="listitem"><p>START_TIME: Timestamp representing the time the execution was
|
|
started.</p></li><li class="listitem"><p>END_TIME: Timestamp representing the time the execution was
|
|
finished, regardless of success or failure. An empty value in this
|
|
column even though the job is not currently running indicates that
|
|
there has been some type of error and the framework was unable to
|
|
perform a last save before failing.</p></li><li class="listitem"><p>STATUS: Character string representing the status of the
|
|
execution. This may be COMPLETED, STARTED, etc. The object
|
|
representation of this column is the
|
|
<code class="classname">BatchStatus</code> enumeration.</p></li><li class="listitem"><p>EXIT_CODE: Character string representing the exit code of the
|
|
execution. In the case of a command line job, this may be converted
|
|
into a number.</p></li><li class="listitem"><p>EXIT_MESSAGE: Character string representing a more detailed
|
|
description of how the job exited. In the case of failure, this might
|
|
include as much of the stack trace as is possible.</p></li><li class="listitem"><p>LAST_UPDATED: Timestamp representing the last time this
|
|
execution was persisted.</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="metaDataBatchStepExecution" href="#metaDataBatchStepExecution"></a>B.5 BATCH_STEP_EXECUTION</h2></div></div></div><p>The BATCH_STEP_EXECUTION table holds all information relevant to the
|
|
<code class="classname">StepExecution</code> object. This table is very similar in
|
|
many ways to the BATCH_JOB_EXECUTION table and there will always be at
|
|
least one entry per <code class="classname">Step</code> for each
|
|
<code class="classname">JobExecution</code> created:</p><pre class="programlisting"><span class="hl-keyword">CREATE</span> <span class="hl-keyword">TABLE</span> BATCH_STEP_EXECUTION (
|
|
STEP_EXECUTION_ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">PRIMARY</span> <span class="hl-keyword">KEY</span> ,
|
|
VERSION <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>,
|
|
STEP_NAME <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">100</span>) <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>,
|
|
JOB_EXECUTION_ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>,
|
|
START_TIME <span class="hl-keyword">TIMESTAMP</span> <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span> ,
|
|
END_TIME <span class="hl-keyword">TIMESTAMP</span> <span class="hl-keyword">DEFAULT</span> <span class="hl-keyword">NULL</span>,
|
|
STATUS <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">10</span>),
|
|
COMMIT_COUNT <span class="hl-keyword">BIGINT</span> ,
|
|
READ_COUNT <span class="hl-keyword">BIGINT</span> ,
|
|
FILTER_COUNT <span class="hl-keyword">BIGINT</span> ,
|
|
WRITE_COUNT <span class="hl-keyword">BIGINT</span> ,
|
|
READ_SKIP_COUNT <span class="hl-keyword">BIGINT</span> ,
|
|
WRITE_SKIP_COUNT <span class="hl-keyword">BIGINT</span> ,
|
|
PROCESS_SKIP_COUNT <span class="hl-keyword">BIGINT</span> ,
|
|
ROLLBACK_COUNT <span class="hl-keyword">BIGINT</span> ,
|
|
EXIT_CODE <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">20</span>) ,
|
|
EXIT_MESSAGE <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">2500</span>) ,
|
|
LAST_UPDATED <span class="hl-keyword">TIMESTAMP</span>,
|
|
<span class="hl-keyword">constraint</span> JOB_EXECUTION_STEP_FK <span class="hl-keyword">foreign</span> <span class="hl-keyword">key</span> (JOB_EXECUTION_ID)
|
|
<span class="hl-keyword">references</span> BATCH_JOB_EXECUTION(JOB_EXECUTION_ID)
|
|
) ;</pre><p>Below are descriptions for each column:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>STEP_EXECUTION_ID: Primary key that uniquely identifies this
|
|
execution. The value of this column should be obtainable by calling
|
|
the <code class="methodname">getId</code> method of the
|
|
<code class="classname">StepExecution</code> object.</p></li><li class="listitem"><p>VERSION: See above section.</p></li><li class="listitem"><p>STEP_NAME: The name of the step to which this execution
|
|
belongs.</p></li><li class="listitem"><p>JOB_EXECUTION_ID: Foreign key from the BATCH_JOB_EXECUTION table
|
|
indicating the JobExecution to which this StepExecution belongs. There
|
|
may be only one <code class="classname">StepExecution</code> for a given
|
|
<code class="classname">JobExecution</code> for a given
|
|
<code class="classname">Step</code> name.</p></li><li class="listitem"><p>START_TIME: Timestamp representing the time the execution was
|
|
started.</p></li><li class="listitem"><p>END_TIME: Timestamp representing the time the execution was
|
|
finished, regardless of success or failure. An empty value in this
|
|
column even though the job is not currently running indicates that
|
|
there has been some type of error and the framework was unable to
|
|
perform a last save before failing.</p></li><li class="listitem"><p>STATUS: Character string representing the status of the
|
|
execution. This may be COMPLETED, STARTED, etc. The object
|
|
representation of this column is the
|
|
<code class="classname">BatchStatus</code> enumeration.</p></li><li class="listitem"><p>COMMIT_COUNT: The number of times in which the step has
|
|
committed a transaction during this execution.</p></li><li class="listitem"><p>READ_COUNT: The number of items read during this
|
|
execution.</p></li><li class="listitem"><p>FILTER_COUNT: The number of items filtered out of this
|
|
execution.</p></li><li class="listitem"><p>WRITE_COUNT: The number of items written and committed during
|
|
this execution.</p></li><li class="listitem"><p>READ_SKIP_COUNT: The number of items skipped on read during this
|
|
execution.</p></li><li class="listitem"><p>WRITE_SKIP_COUNT: The number of items skipped on write during
|
|
this execution.</p></li><li class="listitem"><p>PROCESS_SKIP_COUNT: The number of items skipped during
|
|
processing during this execution.</p></li><li class="listitem"><p>ROLLBACK_COUNT: The number of rollbacks during this execution.
|
|
Note that this count includes each time rollback occurs, including
|
|
rollbacks for retry and those in the skip recovery procedure.</p></li><li class="listitem"><p>EXIT_CODE: Character string representing the exit code of the
|
|
execution. In the case of a command line job, this may be converted
|
|
into a number.</p></li><li class="listitem"><p>EXIT_MESSAGE: Character string representing a more detailed
|
|
description of how the job exited. In the case of failure, this might
|
|
include as much of the stack trace as is possible.</p></li><li class="listitem"><p>LAST_UPDATED: Timestamp representing the last time this
|
|
execution was persisted.</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="metaDataBatchJobExecutionContext" href="#metaDataBatchJobExecutionContext"></a>B.6 BATCH_JOB_EXECUTION_CONTEXT</h2></div></div></div><p>The BATCH_JOB_EXECUTION_CONTEXT table holds all information relevant
|
|
to an <code class="classname">Job</code>'s
|
|
<code class="classname">ExecutionContext</code>. There is exactly one
|
|
<code class="classname">Job</code> <code class="classname">ExecutionContext</code> per
|
|
<code class="classname">JobExecution</code>, and it contains all of the job-level
|
|
data that is needed for a particular job execution. This data typically
|
|
represents the state that must be retrieved after a failure so that a
|
|
<code class="classname">JobInstance</code> can 'start from where it left
|
|
off'.</p><pre class="programlisting"><span class="hl-keyword">CREATE</span> <span class="hl-keyword">TABLE</span> BATCH_JOB_EXECUTION_CONTEXT (
|
|
JOB_EXECUTION_ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">PRIMARY</span> <span class="hl-keyword">KEY</span>,
|
|
SHORT_CONTEXT <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">2500</span>) <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>,
|
|
SERIALIZED_CONTEXT <span class="hl-keyword">CLOB</span>,
|
|
<span class="hl-keyword">constraint</span> JOB_EXEC_CTX_FK <span class="hl-keyword">foreign</span> <span class="hl-keyword">key</span> (JOB_EXECUTION_ID)
|
|
<span class="hl-keyword">references</span> BATCH_JOB_EXECUTION(JOB_EXECUTION_ID)
|
|
) ;</pre><p>Below are descriptions for each column:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>JOB_EXECUTION_ID: Foreign key representing the
|
|
<code class="classname">JobExecution</code> to which the context belongs.
|
|
There may be more than one row associated to a given execution.</p></li><li class="listitem"><p>SHORT_CONTEXT: A string version of the
|
|
SERIALIZED_CONTEXT.</p></li><li class="listitem"><p>SERIALIZED_CONTEXT: The entire context, serialized.</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="metaDataBatchStepExecutionContext" href="#metaDataBatchStepExecutionContext"></a>B.7 BATCH_STEP_EXECUTION_CONTEXT</h2></div></div></div><p>The BATCH_STEP_EXECUTION_CONTEXT table holds all information
|
|
relevant to an <code class="classname">Step</code>'s
|
|
<code class="classname">ExecutionContext</code>. There is exactly one
|
|
<code class="classname">ExecutionContext</code> per
|
|
<code class="classname">StepExecution</code>, and it contains all of the data that
|
|
needs to persisted for a particular step execution. This data typically
|
|
represents the state that must be retrieved after a failure so that a
|
|
<code class="classname">JobInstance</code> can 'start from where it left
|
|
off'.</p><pre class="programlisting"><span class="hl-keyword">CREATE</span> <span class="hl-keyword">TABLE</span> BATCH_STEP_EXECUTION_CONTEXT (
|
|
STEP_EXECUTION_ID <span class="hl-keyword">BIGINT</span> <span class="hl-keyword">PRIMARY</span> <span class="hl-keyword">KEY</span>,
|
|
SHORT_CONTEXT <span class="hl-keyword">VARCHAR</span>(<span class="hl-number">2500</span>) <span class="hl-keyword">NOT</span> <span class="hl-keyword">NULL</span>,
|
|
SERIALIZED_CONTEXT <span class="hl-keyword">CLOB</span>,
|
|
<span class="hl-keyword">constraint</span> STEP_EXEC_CTX_FK <span class="hl-keyword">foreign</span> <span class="hl-keyword">key</span> (STEP_EXECUTION_ID)
|
|
<span class="hl-keyword">references</span> BATCH_STEP_EXECUTION(STEP_EXECUTION_ID)
|
|
) ;</pre><p>Below are descriptions for each column:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>STEP_EXECUTION_ID: Foreign key representing the
|
|
<code class="classname">StepExecution</code> to which the context belongs.
|
|
There may be more than one row associated to a given execution.</p></li><li class="listitem"><p>SHORT_CONTEXT: A string version of the
|
|
SERIALIZED_CONTEXT.</p></li><li class="listitem"><p>SERIALIZED_CONTEXT: The entire context, serialized.</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="metaDataArchiving" href="#metaDataArchiving"></a>B.8 Archiving</h2></div></div></div><p>Because there are entries in multiple tables every time a batch job
|
|
is run, it is common to create an archive strategy for the meta-data
|
|
tables. The tables themselves are designed to show a record of what
|
|
happened in the past, and generally won't affect the run of any job, with
|
|
a couple of notable exceptions pertaining to restart:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The framework will use the meta-data tables to determine if a
|
|
particular JobInstance has been run before. If it has been run, and
|
|
the job is not restartable, then an exception will be thrown.</p></li><li class="listitem"><p>If an entry for a JobInstance is removed without having
|
|
completed successfully, the framework will think that the job is new,
|
|
rather than a restart.</p></li><li class="listitem"><p>If a job is restarted, the framework will use any data that has
|
|
been persisted to the ExecutionContext to restore the Job's state.
|
|
Therefore, removing any entries from this table for jobs that haven't
|
|
completed successfully will prevent them from starting at the correct
|
|
point if run again.</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="multiByteCharacters" href="#multiByteCharacters"></a>B.9 International and Multi-byte Characters</h2></div></div></div><p>If you are using multi-byte character sets (e.g. Chines or Cyrillic)
|
|
in your business processing, then those characters might need to be
|
|
persisted in the Spring Batch schema. Many users find that
|
|
simply changing the schema to double the length of the <code class="literal">VARCHAR</code>
|
|
columns is enough. Others prefer to configure the <a class="link" href="configureJob.html#configuringJobRepository" title="4.3 Configuring a JobRepository"><code class="classname">JobRepository</code></a> with <code class="literal">max-varchar-length</code> half the value of the <code class="literal">VARCHAR</code> column length is enough. Some users have also reported that
|
|
they use <code class="literal">NVARCHAR</code> in place of <code class="literal">VARCHAR</code>
|
|
in their schema definitions. The best result will depend on the database
|
|
platform and the way the database server has been configured locally.</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="recommendationsForIndexingMetaDataTables" href="#recommendationsForIndexingMetaDataTables"></a>B.10 Recommendations for Indexing Meta Data Tables</h2></div></div></div><p>Spring Batch provides DDL samples for the meta-data tables in the
|
|
Core jar file for several common database platforms. Index declarations
|
|
are not included in that DDL because there are too many variations in how
|
|
users may want to index depending on their precise platform, local
|
|
conventions and also the business requirements of how the jobs will be
|
|
operated. The table below provides some indication as to which columns are
|
|
going to be used in a WHERE clause by the Dao implementations provided by
|
|
Spring Batch, and how frequently they might be used, so that individual
|
|
projects can make up their own minds about indexing.</p><div class="table"><a name="d5e4771" href="#d5e4771"></a><p class="title"><b>Table B.1. Where clauses in SQL statements (excluding primary keys) and
|
|
their approximate frequency of use.</b></p><div class="table-contents"><table summary="Where clauses in SQL statements (excluding primary keys) and
 their approximate frequency of use." style="border-collapse: collapse;border-top: 0.5pt solid ; border-bottom: 0.5pt solid ; border-left: 0.5pt solid ; border-right: 0.5pt solid ; "><colgroup><col><col><col></colgroup><tbody><tr><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">Default Table Name</td><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">Where Clause</td><td style="border-bottom: 0.5pt solid ; ">Frequency</td></tr><tr><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">BATCH_JOB_INSTANCE</td><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">JOB_NAME = ? and JOB_KEY = ?</td><td style="border-bottom: 0.5pt solid ; ">Every time a job is launched</td></tr><tr><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">BATCH_JOB_EXECUTION</td><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">JOB_INSTANCE_ID = ?</td><td style="border-bottom: 0.5pt solid ; ">Every time a job is restarted</td></tr><tr><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">BATCH_EXECUTION_CONTEXT</td><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">EXECUTION_ID = ? and KEY_NAME = ?</td><td style="border-bottom: 0.5pt solid ; ">On commit interval, a.k.a. chunk</td></tr><tr><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">BATCH_STEP_EXECUTION</td><td style="border-right: 0.5pt solid ; border-bottom: 0.5pt solid ; ">VERSION = ?</td><td style="border-bottom: 0.5pt solid ; ">On commit interval, a.k.a. chunk (and at start and end of
|
|
step)</td></tr><tr><td style="border-right: 0.5pt solid ; ">BATCH_STEP_EXECUTION</td><td style="border-right: 0.5pt solid ; ">STEP_NAME = ? and JOB_EXECUTION_ID = ?</td><td style="">Before each step execution</td></tr></tbody></table></div></div><br class="table-break"></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="listOfReadersAndWriters.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="transactions.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix A. List of ItemReaders and ItemWriters </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix C. Batch Processing and Transactions</td></tr></table></div></body></html> |