skip to content

Launching, Parameters & Metadata

2 roadmaps34 questions

Starting jobs and remembering what happened: the launcher, job parameters and identity, the metadata repository, restartability, idempotency, the operator API, and step-scoped late binding. This is the operational half of Spring Batch.

part ofSpring Frameworkoverview, primer and where to startread it →
on this pageshow

explore

questions

page 2 of 2

How are JobParameters validated and converted, and how would you enforce required parameters?

level: seniorimportance: nice to knowfreq 30%

basics

~10 s

Attach a JobParametersValidator to the job (DefaultJobParametersValidator for required/optional key checks, or a custom one) to fail fast on bad input. Conversion from string form uses a JobParametersConverter / ConversionService in Spring Batch 5.

open as a page

In production, how would you wire up a JobOperator and expose it so operators can manage jobs (e.g., over JMX or an admin endpoint)? What are the pitfalls?

level: principalimportance: nice to knowfreq 28%

basics

~20 s

Define a SimpleJobOperator bean wired with JobLauncher, JobRegistry, JobRepository, and JobExplorer, and make sure every Job is registered in the JobRegistry so it can be found by name. Then expose the operator via a JMX MBean or a secured admin controller.

open as a page

What production concerns arise from the JobRepository metadata store, and how do you configure it for a clustered deployment?

level: principalimportance: nice to knowfreq 25%

basics

~20 s

Use a shared, persistent database (not an in-memory store) so all nodes see the same metadata. Manage the schema via Flyway/Liquibase (initialize-schema=never), share one DataSource/transaction manager, and rely on isolation-on-create plus locks to prevent duplicate concurrent launches.

open as a page

You inherit a nightly batch job that 'never resumes' after failures — it always reprocesses everything. Walk through the likely causes and how restart correctness depends on job/step design.

level: principalimportance: nice to knowfreq 20%

basics

~20 s

Most often the job adds a unique identifying parameter (timestamp/UUID) each run, so every launch is a NEW JobInstance and there's nothing to resume. Other causes: readers with saveState=false or no ItemStream, an in-memory JobRepository losing state, or restartable=false.

open as a page

showing 31–34 of 34