What is the ExecutionContext in Spring Batch, and what is it used for?
answer
- key/value map persisted in JobRepository
- step-scoped + job-scoped, not shared
- putLong/getString typed accessors
- survives restart -> readers resume
- small state only
basics
~20 sExecutionContext is a persisted key/value map Spring Batch attaches to a running job or step. It stores state — like how many items were read — so if the job stops and restarts, it can pick up where it left off.
solid answer
~40 sThe ExecutionContext is a serializable String-keyed map that Spring Batch persists in the JobRepository. Every StepExecution has its own step-scoped context and every JobExecution has a job-scoped context. Framework components and your code stash small pieces of state in it — item-read counts, file cursor positions, running totals. Because it is written to the database at chunk-commit boundaries, it survives a crash: when you restart a failed job the same context is reloaded, so a reader can skip already-processed items instead of starting over. You read/write it with typed accessors like putLong, putString, put and getLong/getString. It is meant for small state, not for passing large data between steps.
code
java · 11 linespublic class CountingTasklet implements Tasklet {
@Override
public RepeatStatus execute(StepContribution contribution, ChunkContext chunkContext) {
ExecutionContext ctx = chunkContext.getStepContext()
.getStepExecution().getExecutionContext();
long processed = ctx.getLong("processed", 0L); // second arg = default
processed += doWork();
ctx.putLong("processed", processed); // marks context dirty; persisted at commit
return RepeatStatus.FINISHED;
}
}go deeper
Should know it is a persisted key/value store used for resuming.
Should distinguish step vs job scope and know it lives in the JobRepository DB.
Should tie persistence timing (chunk commit) to restart semantics.
Should reason about serialization, size limits, and it as a design boundary (not a data bus).
## What it is The `ExecutionContext` (`org.springframework.batch.item.ExecutionContext`) is a **persisted, serializable key/value map** — essentially a `Map<String, Object>` with typed accessors — that Spring Batch uses to carry state across the lifecycle of a batch execution, including across JVM restarts. ## Two scopes There are **two distinct contexts**, and they are not automatically shared: - **Step ExecutionContext** — one per `StepExecution`. Scoped to a single step run. This is where readers store their progress. - **Job ExecutionContext** — one per `JobExecution`. Scoped to the whole job run, useful for sharing a value across steps (with promotion — see the listener question). You obtain them from the `StepExecution`/`JobExecution` objects: `stepExecution.getExecutionContext()` and `stepExecution.getJobExecution().getExecutionContext()`. ## Typed accessors Instead of casting, you use `putLong`, `putInt`, `putDouble`, `putString`, and generic `put(key, obj)`, plus `getLong`, `getString`, `get`, `containsKey`. There is also a `dirty` flag: mutations mark the context dirty so the framework knows it must be re-persisted. ## Where it lives The `JobRepository` serializes the context into database tables — `BATCH_STEP_EXECUTION_CONTEXT` and `BATCH_JOB_EXECUTION_CONTEXT` (columns like `SHORT_CONTEXT` and `SERIALIZED_CONTEXT`). Serialization is handled by an `ExecutionContextSerializer` (Jackson-based by default in modern Spring Batch). ## Why it matters — restartability The step context is persisted **at each chunk commit**. So after processing chunk N, the count/cursor is durable. If the JVM dies mid-job, restarting the same `JobInstance` reloads the saved context and stateful readers (`FlatFileItemReader`, `JdbcCursorItemReader`, etc.) resume from where they stopped rather than reprocessing everything. ## Gotchas - Keep it **small** — the DB columns are size-limited; don't stuff large objects or collections. - Values must be **serializable** by the configured serializer. - Step and job contexts are **separate** — writing to the step context does not make a value visible to later steps. ## When to use Use it for small resumable state and cross-step signals. Do **not** use it as a general data bus for large payloads — that is what item readers/writers and staging tables are for.
- Where is the ExecutionContext actually stored?In the JobRepository — serialized into the BATCH_STEP_EXECUTION_CONTEXT and BATCH_JOB_EXECUTION_CONTEXT tables, via an ExecutionContextSerializer (Jackson-based by default).
- If I put a value in the step context, can the next step read it?No. Step and job contexts are separate. You must promote the key to the job context (e.g. with ExecutionContextPromotionListener) for a later step to see it.
saying these in an interview costs you the question
- Thinking there is one shared context for the whole job
- Believing it lives only in memory and is lost on restart
- Using it to pass large datasets between steps