One key issue when executing a batch job concerns the behavior of a job when it is restarted. The launching of a job is considered to be a ‘restart’ if a job execution already exists for the particular job instance. Ideally, all jobs should be able to start up where they left off, but there are scenarios where this is not possible. It is entirely up to the developer to ensure that a new job instance is created in this scenario. However, Spring Batch does provide some help.
JEM, the BEE provides a set of beans to use the SpringBatch restartibility out-of-the-box therefore the developer can be concentrated only on the business logic and use the StepExceution and JobExecution beans to save the check point during the execution. The SpringBatch leverages on the following beans to implement the restartability:
- JobRepository, bean name “jobRepository”: is used for basic CRUD operations of the various persisted domain objects within Spring Batch, such as JobExecution and StepExecution
- JobExplorer, bean name “jobExplorer”: is the ability to query the repository for existing executions.
- TransactionManager, bean name “transactionManager”: is to ensure that the batch meta data, including state that is necessary for restarts after a failure, is persisted correctly.
JEM provides 3 specific implementations of the previous beans to use the OOTB restartability.
Read here for more details.