Backend interview prep

Start

Spring Batch Job Restartability Interview Questions and Answers

Master Spring Batch Job Restartability with interview questions covering JobRepository, ExecutionContext, checkpoints, restartability, JobInstance, JobExecution, failed jobs, idempotency, and enterprise production best practices.

Introduction

One of the biggest advantages of Spring Batch over custom batch processing solutions is Job Restartability.

Imagine processing a 5 million-row CSV file that runs for 4 hours. If the application crashes after processing 4.2 million records, restarting the entire job would waste hours of processing time.

Spring Batch solves this problem by automatically storing execution metadata and checkpoints in the JobRepository, allowing failed jobs to resume from the last successful checkpoint.

Restartability is one of the most frequently asked topics in Spring Batch interviews for banking, insurance, healthcare, and financial systems.

Job Restartability Architecture

flowchart LR

Scheduler --> JobLauncher

JobLauncher --> Job

Job --> Step

Step --> ItemReader

ItemReader --> ItemProcessor

ItemProcessor --> ItemWriter

ItemWriter --> Database

Step --> ExecutionContext

ExecutionContext --> JobRepository

JobRepository --> BatchMetadataTables

Q1. What is Job Restartability?

Answer

Job Restartability is the ability to restart a failed batch job from the last successful checkpoint instead of starting from the beginning.

Example

5,000,000 Records

↓

Processed 4,200,000

↓

Application Crash

↓

Restart

↓

Continue From 4,200,001

Advantages

  • Saves processing time
  • Avoids duplicate work
  • Improves reliability
  • Reduces operational costs

Q2. How does Restartability work?

Spring Batch stores execution metadata in the JobRepository.

Stored Information

  • JobExecution
  • StepExecution
  • ExecutionContext
  • Job Parameters
  • Read Count
  • Write Count
  • Commit Count

Restart Flow

flowchart TD

JobStart --> ProcessChunk

ProcessChunk --> SaveCheckpoint

SaveCheckpoint --> JobRepository

JobRepository --> Failure

Failure --> Restart

Restart --> ResumeProcessing

Q3. What is ExecutionContext?

ExecutionContext stores state information required for restarting.

Example

executionContext.putLong(
"lastProcessedId",
4200000L
);

Restart

Long id =
executionContext.getLong(
"lastProcessedId"
);

ExecutionContext acts as the checkpoint storage.

Q4. What information is stored in ExecutionContext?

Typical data

  • Current Row Number
  • File Offset
  • Last Processed ID
  • Page Number
  • Current Partition
  • Custom State

Example

lastRow = 450000

currentPage = 450

partition = 3

Q5. What is JobRepository?

JobRepository stores all batch execution metadata.

Architecture

flowchart TD

Job --> JobRepository

JobRepository --> BATCH_JOB_INSTANCE

JobRepository --> BATCH_JOB_EXECUTION

JobRepository --> BATCH_STEP_EXECUTION

JobRepository --> BATCH_JOB_EXECUTION_CONTEXT

JobRepository --> BATCH_STEP_EXECUTION_CONTEXT

Without JobRepository,

restartability is not possible.

Q6. What is the difference between JobInstance and JobExecution?

JobInstance JobExecution
Logical job Physical execution
Created once Created every run
Identified by JobParameters Linked to JobInstance
Business representation Runtime execution

Example

CustomerImport

↓

Execution #1

FAILED

↓

Execution #2

COMPLETED

Q7. How does checkpointing work?

Checkpointing saves progress after every successful chunk.

Example

Chunk Size = 1000

↓

Commit

↓

Save Checkpoint

Checkpoint Flow

flowchart LR

Read1000 --> Process1000

Process1000 --> Write1000

Write1000 --> Commit

Commit --> SaveCheckpoint

If a failure occurs,

the next restart begins from the saved checkpoint.

Q8. What makes a Job Restartable?

A restartable job should

  • Use JobRepository
  • Store state in ExecutionContext
  • Use deterministic readers
  • Support idempotent writes
  • Avoid duplicate inserts

Example

reader.setSaveState(true);

Most built-in Spring Batch readers support restartability automatically.

Q9. What is Idempotency?

Idempotency means running the same job multiple times produces the same result.

Example

Import Customer

↓

Run Once

↓

100 Records

↓

Run Again

↓

Still 100 Records

Avoid

  • Duplicate inserts
  • Duplicate emails
  • Duplicate payments

Techniques

  • UPSERT
  • MERGE
  • Unique Constraints
  • Business Keys

Q10. Restartability Best Practices

Use Chunk Processing

Checkpoints occur after every chunk commit.

Keep Readers Restartable

Enable state saving.

Use Job Parameters

Different parameters create different JobInstances.

Make Writes Idempotent

Avoid duplicate business data.

Monitor Failed Executions

Analyze failed JobExecutions before restarting.

Banking Example

flowchart TD

TransactionCSV --> Reader

Reader --> Processor

Processor --> Writer

Writer --> PostgreSQL

Writer --> JobRepository

JobRepository --> Failure

Failure --> Restart

Restart --> Continue

Common Interview Questions

  • What is Job Restartability?
  • How does Spring Batch restart failed jobs?
  • What is ExecutionContext?
  • What is checkpointing?
  • JobInstance vs JobExecution?
  • What is JobRepository?
  • What is idempotency?
  • How do you make a job restartable?
  • Why are JobParameters important?
  • Restartability best practices?

Quick Revision

Topic Summary
Restartability Resume failed jobs
ExecutionContext Stores checkpoint state
JobRepository Stores execution metadata
JobExecution Runtime execution
JobInstance Logical job
Checkpoint Last committed position
Chunk Restart boundary
JobParameters Identify JobInstance
Idempotency Safe repeated execution
Metadata Tables Persist batch state

Restart Lifecycle

sequenceDiagram
Scheduler->>JobLauncher: Start Job
JobLauncher->>Job: Execute
Job->>Step: Process Chunk
Step->>JobRepository: Save Checkpoint
Step-->>Job: Failure
Scheduler->>JobLauncher: Restart Job
JobLauncher->>JobRepository: Load Checkpoint
JobRepository-->>JobLauncher: Last Position
JobLauncher->>Step: Resume Processing
Step-->>Scheduler: Completed

Production Example – Processing 5 Million Transactions

A banking application imports 5 million transactions every night.

Configuration

  • Chunk Size = 1000
  • JdbcPagingItemReader
  • JdbcBatchItemWriter
  • JobRepository enabled
  • ExecutionContext enabled

Execution

  • 4,250 chunks complete successfully.
  • Chunk 4,251 fails because the database becomes unavailable.
  • Job status becomes FAILED.
  • After the database is restored, the scheduler restarts the job.
  • Spring Batch retrieves the last committed checkpoint from the JobRepository.
  • Processing resumes from Chunk 4,251, not from the beginning.
flowchart LR

5MillionRows --> Chunk1

Chunk1 --> Chunk2

Chunk2 --> Chunk4250

Chunk4250 --> Commit

Commit --> Checkpoint

Checkpoint --> Chunk4251

Chunk4251 --> DatabaseFailure

DatabaseFailure --> Restart

Restart --> Checkpoint

Checkpoint --> Chunk4251

This capability saves hours of processing time and is a major reason Spring Batch is widely adopted in enterprise systems.

Key Takeaways

  • Job Restartability enables Spring Batch to resume failed jobs from the last successful checkpoint instead of restarting from the beginning.
  • JobRepository stores execution metadata, including JobExecution, StepExecution, and ExecutionContext.
  • ExecutionContext maintains checkpoint information such as the last processed row, page number, or partition state.
  • Checkpointing occurs after successful chunk commits and defines where processing resumes after failure.
  • JobInstance represents the logical batch job, while JobExecution represents each execution attempt.
  • Restartable jobs should use deterministic readers, persist state, and implement idempotent writes to avoid duplicate business data.
  • Proper restartability significantly reduces processing time, improves fault tolerance, and increases reliability for long-running enterprise batch jobs.