Spring/spring-batch
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update docs

Browse Source 
Fix incorrect git meta-data (<<<<<<< HEAD)
introduced mistakenly in efdce56 which was
causing asciidoc warnings
This commit is contained in:
Mahmoud Ben Hassine
2020-05-29 21:19:54 +02:00
parent 121a48375c
commit 09646d8938
1 changed files with 217 additions and 226 deletions
Download Patch File Download Diff File Expand all files Collapse all files

443
spring-batch-docs/asciidoc/jsr-352.adoc
View File

@@ -10,60 +10,66 @@ ifndef::onlyonetoggle[]
include::toggle.adoc[]
endif::onlyonetoggle[]
As of Spring Batch 3.0 support for JSR-352 has been fully implemented. This section is not
a replacement for the spec itself and instead, intends to explain how the JSR-352 specific
concepts apply to Spring Batch. Additional information on JSR-352 can be found via the
JCP here:
link:$$https://jcp.org/en/jsr/detail?id=352$$[https://jcp.org/en/jsr/detail?id=352]
As of Spring Batch 3.0 support for JSR-352 has been fully implemented. This section is not a replacement for
the spec itself and instead, intends to explain how the JSR-352 specific concepts apply to Spring Batch.
Additional information on JSR-352 can be found via the
JCP here: link:$$https://jcp.org/en/jsr/detail?id=352$$[https://jcp.org/en/jsr/detail?id=352]
[[jsrGeneralNotes]]
=== General Notes about Spring Batch and JSR-352
Spring Batch and JSR-352 are structurally the same. They both have jobs that are made up
of steps. They both have readers, processors, writers, and listeners. However, their
interactions are subtly different. For example, the
`org.springframework.batch.core.SkipListener#onSkipInWrite(S item, Throwable t)` within
Spring Batch receives two parameters: the item that was skipped and the Exception that
caused the skip. The JSR-352 version of the same method
Spring Batch and JSR-352 are structurally the same. They both have jobs that are made up of steps. They
both have readers, processors, writers, and listeners. However, their interactions are subtly different.
For example, the `org.springframework.batch.core.SkipListener#onSkipInWrite(S item, Throwable t)`
within Spring Batch receives two parameters: the item that was skipped and the Exception that caused the
skip. The JSR-352 version of the same method
(`javax.batch.api.chunk.listener.SkipWriteListener#onSkipWriteItem(List&lt;Object&gt; items, Exception ex)`)
also receives two parameters. However the first one is a `List` of all the items within
the current chunk with the second being the `Exception` that caused the skip. Because of
these differences, it is important to note that there are two paths to execute a job
within Spring Batch: either a traditional Spring Batch job or a JSR-352 based job. While
the use of Spring Batch artifacts (readers, writers, etc) will work within a job
configured with JSR-352's JSL and executed with the `JsrJobOperator`, they behave
according to the rules of JSR-352. It is also important to note that batch artifacts that
have been developed against the JSR-352 interfaces will not work within a traditional
Spring Batch job.
also receives two parameters. However the first one is a `List` of all the items
within the current chunk with the second being the `Exception` that caused the skip.
Because of these differences, it is important to note that there are two paths to execute a job within
Spring Batch: either a traditional Spring Batch job or a JSR-352 based job. While the use of Spring Batch
artifacts (readers, writers, etc) will work within a job configured with JSR-352's JSL and executed with the
`JsrJobOperator`, they will behave according to the rules of JSR-352. It is also
important to note that batch artifacts that have been developed against the JSR-352 interfaces will not work
within a traditional Spring Batch job.
[[jsrSetup]]
=== Setup
[[jsrSetupContexts]]
==== Application Contexts
All JSR-352 based jobs within Spring Batch consist of two application contexts. A parent
context, that contains beans related to the infrastructure of Spring Batch such as the
`JobRepository`, `PlatformTransactionManager`, etc and a child context that consists of
the configuration of the job to be run. The parent context is defined via the
`baseContext.xml` provided by the framework. This context may be overridden by setting
the `JSR-352-BASE-CONTEXT` system property.
All JSR-352 based jobs within Spring Batch consist of two application contexts. A parent context, that
contains beans related to the infrastructure of Spring Batch such as the `JobRepository`,
`PlatformTransactionManager`, etc and a child context that consists of the configuration
of the job to be run. The parent context is defined via the `jsrBaseContext.xml` provided
by the framework. This context may be overridden by setting the `JSR-352-BASE-CONTEXT` system
property.
[NOTE]
====
The base context is not processed by the JSR-352 processors for things like property
injection so that no components requiring that additional processing should be configured
there.
The base context is not processed by the JSR-352 processors for things like property injection so
no components requiring that additional processing should be configured there.
====
[[jsrSetupLaunching]]
==== Launching a JSR-352 based job
JSR-352 requires a very simple path to executing a batch job. The following code is all
that is needed to execute your first batch job:
JSR-352 requires a very simple path to executing a batch job. The following code is all that is needed to
execute your first batch job:
[source, java]
----
@@ -71,91 +77,101 @@ JobOperator operator = BatchRuntime.getJobOperator();
jobOperator.start("myJob", new Properties());
----
While that is convenient for developers, the devil is in the details. Spring Batch
bootstraps a bit of infrastructure behind the scenes that a developer may want to
override. The following is bootstrapped the first time `BatchRuntime.getJobOperator()`
is called:
While that is convenient for developers, the devil is in the details. Spring Batch bootstraps a bit of
infrastructure behind the scenes that a developer may want to override. The following is bootstrapped the
first time `BatchRuntime.getJobOperator()` is called:
|===============
|__Bean Name__|__Default Configuration__|__Notes__
|
dataSource
|
Apache DBCP BasicDataSource with configured values.
|
By default, HSQLDB is bootstrapped.
dataSource
|
Apache DBCP BasicDataSource with configured values.
|
By default, HSQLDB is bootstrapped.
|`transactionManager`|`org.springframework.jdbc.datasource.DataSourceTransactionManager`|
References the dataSource bean defined above.
References the dataSource bean defined above.
|
A Datasource initializer
||
This is configured to execute the scripts configured via the `batch.drop.script` and
`batch.schema.script` properties. By default, the schema scripts for HSQLDB are executed.
This behavior can be disabled by setting the `batch.data.source.init` property.
A Datasource initializer
||
This is configured to execute the scripts configured via the
`batch.drop.script` and `batch.schema.script` properties. By
default, the schema scripts for HSQLDB are executed. This behavior can be disabled by setting the
`batch.data.source.init` property.
|
jobRepository
|
A JDBC based `SimpleJobRepository`.
|
This `JobRepository` uses the previously mentioned data source and transaction
manager. The schema's table prefix is configurable (defaults to BATCH_) via the
`batch.table.prefix` property.
jobRepository
|
A JDBC based `SimpleJobRepository`.
|
This `JobRepository` uses the previously mentioned data source and transaction
manager. The schema's table prefix is configurable (defaults to BATCH_) via the
`batch.table.prefix` property.
|
jobLauncher
|`org.springframework.batch.core.launch.support.SimpleJobLauncher`|
Used to launch jobs.
jobLauncher
|`org.springframework.batch.core.launch.support.SimpleJobLauncher`|
Used to launch jobs.
|
batchJobOperator
|`org.springframework.batch.core.launch.support.SimpleJobOperator`|
The `JsrJobOperator` wraps this to provide most of it's functionality.
batchJobOperator
|`org.springframework.batch.core.launch.support.SimpleJobOperator`|
The `JsrJobOperator` wraps this to provide most of it's functionality.
|
jobExplorer
|`org.springframework.batch.core.explore.support.JobExplorerFactoryBean`|
Used to address lookup functionality provided by the `JsrJobOperator`.
jobExplorer
|`org.springframework.batch.core.explore.support.JobExplorerFactoryBean`|
Used to address lookup functionality provided by the `JsrJobOperator`.
|
jobParametersConverter
|`org.springframework.batch.core.jsr.JsrJobParametersConverter`|
JSR-352 specific implementation of the `JobParametersConverter`.
jobParametersConverter
|`org.springframework.batch.core.jsr.JsrJobParametersConverter`|
JSR-352 specific implementation of the `JobParametersConverter`.
|
jobRegistry
|`org.springframework.batch.core.configuration.support.MapJobRegistry`|
Used by the `SimpleJobOperator`.
jobRegistry
|`org.springframework.batch.core.configuration.support.MapJobRegistry`|
Used by the `SimpleJobOperator`.
|
placeholderProperties
|`org.springframework.beans.factory.config.PropertyPlaceholderConfigure`|
Loads the properties file `batch-${ENVIRONMENT:hsql}.properties` to configure the
properties mentioned above. ENVIRONMENT is a System property (defaults to `hsql`) that
can be used to specify any of the supported databases Spring Batch currently supports.
placeholderProperties
|`org.springframework.beans.factory.config.PropertyPlaceholderConfigure`|
Loads the properties file `batch-${ENVIRONMENT:hsql}.properties` to configure
the properties mentioned above. ENVIRONMENT is a System property (defaults to `hsql`)
that can be used to specify any of the supported databases Spring Batch currently
supports.
|===============
[NOTE]
====
None of the above beans are optional for executing JSR-352 based jobs. All may be
overridden to provide customized functionality as needed.
None of the above beans are optional for executing JSR-352 based jobs. All may be overridden to
provide customized functionality as needed.
====
[[dependencyInjection]]
=== Dependency Injection
JSR-352 is based heavily on the Spring Batch programming model. As such, while not
explicitly requiring a formal dependency injection implementation, DI of some kind
implied. Spring Batch supports all three methods for loading batch artifacts defined by
JSR-352:
JSR-352 is based heavily on the Spring Batch programming model. As such, while not explicitly requiring a
formal dependency injection implementation, DI of some kind implied. Spring Batch supports all three
methods for loading batch artifacts defined by JSR-352:
* Implementation Specific Loader: Spring Batch is built upon Spring and so supports
Spring dependency injection within JSR-352 batch jobs.
* Archive Loader: JSR-352 defines the existing of a batch.xml file that provides mappings
between a logical name and a class name. This file must be found within the /META-INF/
* Archive Loader: JSR-352 defines the existing of a `batch.xml` file that provides mappings
between a logical name and a class name. This file must be found within the `/META-INF/`
directory if it is used.
* Thread Context Class Loader: JSR-352 allows configurations to specify batch artifact
implementations in their JSL by providing the fully qualified class name inline. Spring
@@ -164,7 +180,7 @@ Batch supports this as well in JSR-352 configured jobs.
To use Spring dependency injection within a JSR-352 based batch job consists of
configuring batch artifacts using a Spring application context as beans. Once the beans
have been defined, a job can refer to them as it would any bean defined within the
batch.xml file.
`batch.xml` file.
[role="xmlContent"]
The following example shows how to use Spring dependency injection within a JSR-352 based
@@ -222,14 +238,14 @@ public class BatchConfiguration {
</job>
----
The assembly of Spring contexts (imports, etc) works with JSR-352 jobs just as it would
with any other Spring based application. The only difference with a JSR-352 based job is
that the entry point for the context definition will be the job definition found in /META-INF/batch-jobs/.
The assembly of Spring contexts (imports, etc) works with JSR-352 jobs just as it would with any other
Spring based application. The only difference with a JSR-352 based job is that the entry point for the
context definition will be the job definition found in /META-INF/batch-jobs/.
To use the thread context class loader approach, all you need to do is provide the fully qualified class
name as the ref. It is important to note that when using this approach or the `batch.xml` approach, the class
referenced requires a no argument constructor which will be used to create the bean.
To use the thread context class loader approach, all you need to do is provide the fully
qualified class name as the ref. It is important to note that when using this approach or
the batch.xml approach, the class referenced requires a no argument constructor which is
used to create the bean.
[source, xml]
----
@@ -243,6 +259,8 @@ used to create the bean.
----
[[jsrJobProperties]]
=== Batch Properties
[[jsrPropertySupport]]
@@ -250,9 +268,9 @@ used to create the bean.
==== Property Support
JSR-352 allows for properties to be defined at the Job, Step and batch artifact level by
way of configuration in the JSL. Batch properties are configured at each level in the
following way:
JSR-352 allows for properties to be defined at the Job, Step and batch artifact level by way of
configuration in the JSL. Batch properties are configured at each level in the following way:
[source, xml]
----
@@ -262,18 +280,22 @@ following way:
</properties>
----
`Properties` may be configured on any batch artifact.
[[jsrBatchPropertyAnnotation]]
==== @BatchProperty annotation
`Properties` are referenced in batch artifacts by annotating class fields with the
`@BatchProperty` and `@Inject` annotations (both annotations are required by the spec). As
defined by JSR-352, fields for properties must be String typed. Any type conversion is up
to the implementing developer to perform.
`@BatchProperty` and `@Inject` annotations (both annotations
are required by the spec). As defined by JSR-352, fields for properties must be String typed. Any type
conversion is up to the implementing developer to perform.
An `javax.batch.api.chunk.ItemReader` artifact could be configured with a
properties block such as the one described above and accessed as such:
An `javax.batch.api.chunk.ItemReader` artifact could be configured with a properties block
such as the one described above and accessed as such:
[source, java]
----
@@ -286,13 +308,16 @@ public class MyItemReader extends AbstractItemReader {
}
----
The value of the field "propertyName1" will be "propertyValue1"
[[jsrPropertySubstitution]]
==== Property Substitution
Property substitution is provided by way of operators and simple conditional expressions.
The general usage is `#{operator['key']}`.
Property substitution is provided by way of operators and simple conditional expressions. The general
usage is `#{operator['key']}`.
Supported operators:
@@ -314,23 +339,26 @@ used, which are separated by a ';'.
[[jsrProcessingModels]]
=== Processing Models
JSR-352 provides the same two basic processing models that Spring Batch does:
* Item based processing - Using an `javax.batch.api.chunk.ItemReader`, an optional
`javax.batch.api.chunk.ItemProcessor`, and an `javax.batch.api.chunk.ItemWriter`.
* Task based processing - Using a `javax.batch.api.Batchlet` implementation. This
processing model is the same as the `org.springframework.batch.core.step.tasklet.Tasklet`
based processing currently available.
* Task based processing - Using a `javax.batch.api.Batchlet`
implementation. This processing model is the same as the
`org.springframework.batch.core.step.tasklet.Tasklet` based processing
currently available.
==== Item based processing
Item based processing in this context is a chunk size being set by the number of items
read by an `ItemReader`. To configure a step this way, specify the `item-count` (which
defaults to 10) and optionally configure the `checkpoint-policy` as item (this is the default).
Item based processing in this context is a chunk size being set by the number of items read by an
`ItemReader`. To configure a step this way, specify the
`item-count` (which defaults to 10) and optionally configure the
`checkpoint-policy` as item (this is the default).
[source, xml]
----
@@ -359,9 +387,10 @@ enough in many cases. Because of this, the spec allows for the implementation of
checkpointing algorithm by implementing the `javax.batch.api.chunk.CheckpointAlgorithm`
interface. This functionality is functionally the same as Spring Batch's custom completion
policy. To use an implementation of `CheckpointAlgorithm`, configure your step with the
custom `checkpoint-policy` as shown below where fooCheckpointer refers to an
custom `checkpoint-policy` as shown below where `fooCheckpointer` refers to an
implementation of `CheckpointAlgorithm`.
[source, xml]
----
...
@@ -377,19 +406,22 @@ implementation of `CheckpointAlgorithm`.
----
[[jsrRunningAJob]]
=== Running a job
The entrance to executing a JSR-352 based job is through the
`javax.batch.operations.JobOperator`. Spring Batch provides our own implementation to
this interface (`org.springframework.batch.core.jsr.launch.JsrJobOperator`). This
implementation is loaded via the `javax.batch.runtime.BatchRuntime`. Launching a
`javax.batch.operations.JobOperator`. Spring Batch provides its own implementation of
this interface (`org.springframework.batch.core.jsr.launch.JsrJobOperator`). This
implementation is loaded via the `javax.batch.runtime.BatchRuntime`. Launching a
JSR-352 based batch job is implemented as follows:
[source, java]
----
JobOperator jobOperator = BatchRuntime.getJobOperator();
long jobExecutionId = jobOperator.start("fooJob", new Properties());
----
The above code does the following:
@@ -403,7 +435,7 @@ components that are bootstrapped are similar to those provided by
above, the framework looks in /META-INF/batch-jobs for a file named fooJob.xml and load a
context that is a child of the shared context mentioned previously.
* Launch the job: The job defined within the context will be executed asynchronously.
The `JobExecution's` ID is returned.
The `JobExecution's` ID will be returned.
[NOTE]
====
@@ -413,30 +445,34 @@ All JSR-352 based batch jobs are executed asynchronously.
When `JobOperator#start` is called using `SimpleJobOperator`, Spring Batch determines if
the call is an initial run or a retry of a previously executed run. Using the JSR-352
based `JobOperator#start(String jobXMLName, Properties jobParameters)`, the framework
always creates a new JobInstance (JSR-352 job parameters are non-identifying). In order to
will always create a new JobInstance (JSR-352 job parameters are non-identifying). In order to
restart a job, a call to
`JobOperator#restart(long executionId, Properties restartParameters)` is required.
[[jsrContexts]]
=== Contexts
JSR-352 defines two context objects that are used to interact with the meta-data of a job
or step from within a batch artifact: `javax.batch.runtime.context.JobContext` and
`javax.batch.runtime.context.StepContext`. Both of these are available in any step-level
artifact (`Batchlet`, `ItemReader`, and others) with the `JobContext` being available to
job-level artifacts as well (JobListener for example).
JSR-352 defines two context objects that are used to interact with the meta-data of a job or step from
within a batch artifact: `javax.batch.runtime.context.JobContext` and
`javax.batch.runtime.context.StepContext`. Both of these are available in any step
level artifact (`Batchlet`, `ItemReader`, etc) with the
`JobContext` being available to job level artifacts as well
(`JobListener` for example).
To obtain a reference to the `JobContext` or `StepContext`
within the current scope, simply use the `@Inject` annotation:
To obtain a reference to the `JobContext` or `StepContext` within the current scope, use
the `@Inject` annotation, as follows:
[source, java]
----
@Inject
JobContext jobContext;
----
[NOTE]
.@Autowire for JSR-352 contexts
====
@@ -444,37 +480,46 @@ Using Spring's @Autowire is not supported for the injection of these contexts.
====
In Spring Batch, the `JobContext` and `StepContext` wrap their corresponding execution
objects (`JobExecution` and `StepExecution` respectively). Data stored through
`StepContext#persistent#setPersistentUserData(Serializable data)` is stored in the Spring
Batch `StepExecution#executionContext`.
In Spring Batch, the `JobContext` and `StepContext` wrap their
corresponding execution objects (`JobExecution` and
`StepExecution` respectively). Data stored through
`StepContext#setPersistentUserData(Serializable data)` is stored in the
Spring Batch `StepExecution#executionContext`.
[[jsrStepFlow]]
=== Step Flow
Within a JSR-352 based job, the flow of steps works similarly as it does within Spring
Batch. However, there are a few subtle differences:
Within a JSR-352 based job, the flow of steps works similarly as it does within Spring Batch.
However, there are a few subtle differences:
* Decision's are steps - In a regular Spring Batch job, a decision is a state that does not
have an independent `StepExecution` or any of the rights and
responsibilities that go along with being a full step.. However, with JSR-352, a decision
is a step just like any other and will behave just as any other steps (transactionality,
it gets a `StepExecution`, etc). This means that they are treated the
same as any other step on restarts as well.
* `next` attribute and step transitions - In a regular job, these are
allowed to appear together in the same step. JSR-352 allows them to both be used in the
same step with the next attribute taking precedence in evaluation.
* Decision's are steps - In a regular Spring Batch job, a decision is a state that does
not have an independent `StepExecution` or any of the rights and responsibilities that go
along with being a full step. However, with JSR-352, a decision is a step just like any
other and will behave just as any other steps (transactionality, it gets a
`StepExecution`, and so on). This means that they are treated the same as any other step
on restarts as well.
* `next` attribute and step transitions - In a regular job, these are allowed to appear
together in the same step. JSR-352 allows them to both be used in the same step with the
next attribute taking precedence in evaluation.
* Transition element ordering - In a standard Spring Batch job, transition elements are
sorted from most specific to least specific and evaluated in that order. JSR-352 jobs
evaluate transition elements in the order they are specified in the XML.
[[jsrScaling]]
=== Scaling a JSR-352 batch job
<<<<<<< HEAD
Traditional Spring Batch jobs have four ways of scaling (the last two capable of being executed across
multiple JVMs):
multiple JVMs):
* Split - Running multiple steps in parallel.
@@ -496,134 +541,80 @@ JSR-352 provides two options for scaling batch jobs. Both options support only
* Partitioning - Conceptually the same as Spring Batch however implemented slightly different.
=======
Traditional Spring Batch jobs have four ways of scaling (the last two capable of being
executed across multiple JVMs):
>>>>>>> Made the "Both" option make sense
* Split: Running multiple steps in parallel.
* Multiple threads: Executing a single step via multiple threads.
* Partitioning: Dividing the data up for parallel processing (master/slave).
* Remote Chunking: Executing the processor piece of logic remotely.
JSR-352 provides two options for scaling batch jobs. Both options support only a single
JVM:
* Split: Same as Spring Batch
* Partitioning: Conceptually the same as Spring Batch however implemented slightly
different.
[[jsrPartitioning]]
==== Partitioning
<<<<<<< HEAD
Conceptually, partitioning in JSR-352 is the same as it is in Spring Batch. Meta-data is provided
to each worker to identify the input to be processed, with the workers reporting back to the manager the
results upon completion. However, there are some important differences:
to each worker to identify the input to be processed, with the workers reporting back to the manager the
results upon completion. However, there are some important differences:
* Partitioned `Batchlet` - This will run multiple instances of the
configured `Batchlet` on multiple threads. Each instance will have
it's own set of properties as provided by the JSL or the
`PartitionPlan`
configured `Batchlet` on multiple threads. Each instance will have
it's own set of properties as provided by the JSL or the
`PartitionPlan`
* `PartitionPlan` - With Spring Batch's partitioning, an
`ExecutionContext` is provided for each partition. With JSR-352, a
single `javax.batch.api.partition.PartitionPlan` is provided with an
array of `Properties` providing the meta-data for each partition.
`ExecutionContext` is provided for each partition. With JSR-352, a
single `javax.batch.api.partition.PartitionPlan` is provided with an
array of `Properties` providing the meta-data for each partition.
* `PartitionMapper` - JSR-352 provides two ways to generate partition
meta-data. One is via the JSL (partition properties). The second is via an implementation
of the `javax.batch.api.partition.PartitionMapper` interface.
Functionally, this interface is similar to the
`org.springframework.batch.core.partition.support.Partitioner`
interface provided by Spring Batch in that it provides a way to programmatically generate
meta-data for partitioning.
meta-data. One is via the JSL (partition properties). The second is via an implementation
of the `javax.batch.api.partition.PartitionMapper` interface.
Functionally, this interface is similar to the
`org.springframework.batch.core.partition.support.Partitioner`
interface provided by Spring Batch in that it provides a way to programmatically generate
meta-data for partitioning.
* `StepExecutions` - In Spring Batch, partitioned steps are run as
manager/worker. Within JSR-352, the same configuration occurs. However, the worker steps do
not get official `StepExecutions`. Because of that, calls to
`JsrJobOperator#getStepExecutions(long jobExecutionId)` will only
return the `StepExecution` for the manager.
=======
Conceptually, partitioning in JSR-352 is the same as it is in Spring Batch. Meta-data is
provided to each slave to identify the input to be processed with the slaves reporting
back to the master the results upon completion. However, there are some important
differences:
* Partitioned `Batchlet`: This runs multiple instances of the configured `Batchlet` on
multiple threads. Each instance has its own set of properties as provided by the JSL or
the `PartitionPlan`.
* `PartitionPlan`: With Spring Batch's partitioning, an `ExecutionContext` is provided
for each partition. With JSR-352, a single `javax.batch.api.partition.PartitionPlan` is
provided with an array of `Properties` providing the meta-data for each partition.
* `PartitionMapper`: JSR-352 provides two ways to generate partition meta-data. One is by
setting the JSL (partition properties). The second is via an implementation of the
`javax.batch.api.partition.PartitionMapper` interface. Functionally, this interface is
similar to the `org.springframework.batch.core.partition.support.Partitioner` interface
provided by Spring Batch in that it provides a way to programmatically generate meta-data
for partitioning.
* `StepExecutions`: In Spring Batch, partitioned steps are run as master/slave. Within
JSR-352, the same configuration occurs. However, the slave steps do not get official
`StepExecutions`. Because of that, calls to
`JsrJobOperator#getStepExecutions(long jobExecutionId)` return only the `StepExecution`
for the master.
>>>>>>> Made the "Both" option make sense
manager/worker. Within JSR-352, the same configuration occurs. However, the worker steps do
not get official `StepExecutions`. Because of that, calls to
`JsrJobOperator#getStepExecutions(long jobExecutionId)` will only
return the `StepExecution` for the manager.
[NOTE]
====
The child `StepExecutions` still exist in the job repository and are available
through the `JobExplorer` and Spring Batch Admin.
through the `JobExplorer`.
====
<<<<<<< HEAD
* Compensating logic - Since Spring Batch implements the manager/worker logic of
partitioning using steps, `StepExecutionListeners` can be used to
handle compensating logic if something goes wrong. However, since the workers JSR-352
provides a collection of other components for the ability to provide compensating logic when
errors occur and to dynamically set the exit status. These components include the following:
partitioning using steps, `StepExecutionListeners` can be used to
handle compensating logic if something goes wrong. However, since the workers JSR-352
provides a collection of other components for the ability to provide compensating logic when
errors occur and to dynamically set the exit status. These components include the following:
|===============
|__Artifact Interface__|__Description__
|`javax.batch.api.partition.PartitionCollector`|Provides a way for worker steps to send information back to the
manager. There is one instance per worker thread.
manager. There is one instance per worker thread.
|`javax.batch.api.partition.PartitionAnalyzer`|End point that receives the information collected by the
`PartitionCollector` as well as the resulting
statuses from a completed partition.
`PartitionCollector` as well as the resulting
statuses from a completed partition.
|`javax.batch.api.partition.PartitionReducer`|Provides the ability to provide compensating logic for a partitioned
step.
=======
* Compensating logic - Since Spring Batch implements the master/slave logic of
partitioning using steps, `StepExecutionListeners` can be used to handle compensating
logic if something goes wrong. However, since the slaves JSR-352 provides a collection of
other components for the ability to provide compensating logic when errors occur and to
dynamically set the exit status. These components include the following:
step.
|===============
|__Artifact Interface__|__Description__
|`javax.batch.api.partition.PartitionCollector`|Provides a way for slave steps to send
information back to the master. There is one instance per slave thread.
|`javax.batch.api.partition.PartitionAnalyzer`|End point that receives the information
collected by the `PartitionCollector` as well as the resulting statuses from a completed
partition.
|`javax.batch.api.partition.PartitionReducer`|Provides the ability to provide compensating
logic for a partitioned step.
>>>>>>> Made the "Both" option make sense
|===============
[[jsrTesting]]
=== Testing
Since all JSR-352 based jobs are executed asynchronously, it can be difficult to determine
when a job has completed. To help with testing, Spring Batch provides the
`org.springframework.batch.core.jsr.JsrTestUtils`. This utility class provides the
ability to start a job and restart a job and wait for it to complete. Once the job
completes, the associated `JobExecution` is returned.
Since all JSR-352 based jobs are executed asynchronously, it can be difficult to determine when a job has
completed. To help with testing, Spring Batch provides the
`org.springframework.batch.test.JsrTestUtils`. This utility class provides the
ability to start a job and restart a job and wait for it to complete. Once the job completes, the
associated `JobExecution` is returned.