This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Boot 3.3.4! |
This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Boot 3.3.4! |
A number of questions often arise when people use Spring Batch from within a Spring Boot application. This section addresses those questions.
Specifying a Batch Data Source
By default, batch applications require a DataSource
to store job details.
Spring Batch expects a single DataSource
by default.
To have it use a DataSource
other than the application’s main DataSource
, declare a DataSource
bean, annotating its @Bean
method with @BatchDataSource
.
If you do so and want two data sources, remember to mark the other one @Primary
.
To take greater control, add @EnableBatchProcessing
to one of your @Configuration
classes or extend DefaultBatchConfiguration
.
See the API documentation of @EnableBatchProcessing
and DefaultBatchConfiguration
for more details.
For more info about Spring Batch, see the Spring Batch project page.
Specifying a Batch Transaction Manager
Similar to Specifying a Batch Data Source, you can define a PlatformTransactionManager
for use in the batch processing by marking it as @BatchTransactionManager
.
If you do so and want two transaction managers, remember to mark the other one as @Primary
.
Running Spring Batch Jobs on Startup
Spring Batch auto-configuration is enabled by adding spring-boot-starter-batch
to your application’s classpath.
If a single Job
bean is found in the application context, it is executed on startup (see JobLauncherApplicationRunner
for details).
If multiple Job
beans are found, the job that should be executed must be specified using spring.batch.job.name
.
To disable running a Job
found in the application context, set the spring.batch.job.enabled
to false
.
See BatchAutoConfiguration
for more details.
Running From the Command Line
Spring Boot converts any command line argument starting with --
to a property to add to the Environment
, see accessing command line properties.
This should not be used to pass arguments to batch jobs.
To specify batch arguments on the command line, use the regular format (that is without --
), as shown in the following example:
$ java -jar myapp.jar someParameter=someValue anotherParameter=anotherValue
If you specify a property of the Environment
on the command line, it is ignored by the job.
Consider the following command:
$ java -jar myapp.jar --server.port=7070 someParameter=someValue
This provides only one argument to the batch job: someParameter=someValue
.
Restarting a Stopped or Failed Job
To restart a failed Job
, all parameters (identifying and non-identifying) must be re-specified on the command line.
Non-identifying parameters are not copied from the previous execution.
This allows them to be modified or removed.
When you’re using a custom JobParametersIncrementer , you have to gather all parameters managed by the incrementer to restart a failed execution.
|
When you’re using a custom JobParametersIncrementer , you have to gather all parameters managed by the incrementer to restart a failed execution.
|
Storing the Job Repository
Spring Batch requires a data store for the Job
repository.
If you use Spring Boot, you must use an actual database.
Note that it can be an in-memory database, see Configuring a Job Repository.