Before this commit, the RunIdIncrementer was failing
with a ClassCastException if the run.id parameter is
not passed as a Long.
This commit makes the RunIdIncrementer more liberal
in what it accepts by trying to parse the parameter
to a Long.
Resolves#3799
This commit deprecates the Map-based JobRepository
and JobExplorer factory beans with the associated
DAOs in favor of using the JDBC-based implementations
with an in-memory database.
Resolves#3780
Calling jobExecution#stop manually is prone to
forgetting to save the job execution in the job
repository.
The way to request a job execution to stop is
by using JobOperator#stop or by using the
CommandLineJobRunner with the "-stop" option.
Both will correctly set the status to STOPPING
and update the job execution in the repository.
Resolves#1605
Before this commit, metrics were not collected in a fault-tolerant step.
This commit updates the FaultTolerantChunkProcessor to collect metrics.
For the record, chunk scanning is not covered for two reasons:
1. When scanning a chunk, there is a single item in each write operation,
so it would be incorrect to report a metric called "chunk.write" for a
single item. We could argue that it is a singleton chunk, but still..
If we want to time scanned (aka individual) items, we need a more fine
grained timer called "scanned.item.write" for example.
2. The end result can be confusing and might distort the overall metrics
view in case of errors (because of the noisy metrics of additional transactions
for individual items).
As a reminder, the goal of the "chunk.write" metric is to give an overview
of the write operation time of the whole chunk and not to time each item
individually (this could be done using an `ItemWriteListener` if needed).
Resolves#3664
Spring Batch orders the transitions as it goes from state to state based
on specificity. The XML configuration has always had this
functionality. However, when creating the JSR-352 implementation, the
mechanism for which this occured was refactored. That occured at about
the same time as the java builders were introduced. Because of this
crossing of paths, the java configuration option for defining jobs has
never correctly sorted the transitions. This PR applys the sorting
algorithm to the java configuration, making XML and java configuration
behave the same.
Resolves#3638
Before this commit, the expected behaviour when a skippbale exception
occurs in a fault tolerant chunk-oriented step was not documented in
details.
This commit update the docs and adds a sample for each case (when a
skippable exception occurs during read, process and write).
Resolves BATCH-2541
ListPreparedStatementSetter is almost a duplicate of
ArgumentPreparedStatementSetter except that it accepts a List of
arguments instead of an array of arguments.
Resolves BATCH-2796
This commit reverts the change to `StepLocator` as it introduces
an inconsistency with `JobLocator` (one returns null and the other
throws an exception when no step/job is found with the given name).
This commit improves the performance of splitting a step execution.
It moves the logic of finding the last step execution of a job instance
to the database (instead of doing it in memory).
Resolves BATCH-2716
This commit fixes the setter of object mapper to copy the configuration
of the custom object mapper provided by the user and "augment" it with
the JobParametersModule.
Resolves BATCH-2828
Before this commit, getting the running job executions loaded
all job executions from the database and filtered them in-memory.
This commit uses `JobExplorer#findRunningJobExecutions` which issues
a query that does the filtering on the database side. This change
considerably improves the performance of stopping a job.
Resolves BATCH-2422
Before this commit, getting the last job instance/execution required to
load all job instances/executions from the database and filter them
on the client side in memory.
This commit introduces new methods that use database queries to get
the last job instance/execution without the need to load all job
instances/executions. This change improves memory consumption as well as
the performance of starting the next instance of a job.
Resolves BATCH-1784
