Understanding Spring Batch Core Components (Complete Guide)

Spring Batch Core Components Explained (Beginner to Advanced)

Spring Batch is far more than just a library for reading and writing data; it is a highly scalable, state-managed orchestration engine. When building enterprise-grade background processes—like billing calculations, massive CSV imports, or nightly data warehouse synchronizations—you need a framework that can guarantee fault tolerance and exact-once processing semantics.

To effectively design, debug, and scale these batch jobs, you must deeply understand its core domain language and components. The entire Spring Batch architecture relies on a strict hierarchy of objects that manage state, track metrics, and orchestrate execution flow.

📺 Complete Video Series:
Want to see these components built from scratch? Watch the full Spring Batch Tutorials Playlist on YouTube.

The 5 Pillars of Spring Batch:
1. JobInstance: The logical definition of a run.
2. JobExecution: The physical execution attempt.
3. StepExecution: The phase-specific execution tracking.
4. JobRepository: The database state manager.
5. JobLauncher: The execution trigger.

1. JobInstance: The Logical Run

A JobInstance represents a logical execution of a job associated with a specific, unique set of identifying JobParameters. This is a crucial concept because it dictates Spring Batch's restartability rules. Spring Batch strictly identifies a job by the combination of its Job Name and its Parameters.

For example, imagine an "End of Day Settlement Job" that runs every night. If you trigger the job with the parameter date=2026-07-18, Spring Batch creates a JobInstance for that specific day. If you attempt to run the exact same job with the exact same date parameter again, Spring Batch will block it and throw a JobInstanceAlreadyCompleteException, ensuring you don't accidentally run the same financial settlement twice. 


JobParameters parameters = new JobParametersBuilder()
    .addString("run.date", "2026-07-18")
    .addLong("run.id", System.currentTimeMillis()) // Using time ensures uniqueness
    .toJobParameters();

jobLauncher.run(dailySettlementJob, parameters);

2. JobExecution: The Physical Attempt

While a JobInstance represents the logical run, a JobExecution represents a single, physical attempt to execute that instance. Understanding the difference between the two is the key to mastering Spring Batch error recovery.

Let's return to our "End of Day" job for date=2026-07-18.

  • Attempt 1: The job starts running, creating our first JobExecution. Halfway through, the database goes offline, and the job crashes. The JobExecution is marked as FAILED.
  • Attempt 2: The database comes back online, and you restart the job with the exact same parameters. Spring Batch retrieves the existing JobInstance and creates a second JobExecution for this new attempt.

The JobExecution object tracks vital runtime context, such as the exact start and end timestamps, the BatchStatus (e.g., STARTED, COMPLETED, FAILED), and any explicit exceptions that caused a crash.

3. StepExecution: Phase-Specific Tracking

A Job is rarely just a single task; it is typically broken down into sequential phases called Steps (e.g., Step 1: Download File, Step 2: Process Data, Step 3: Archive File). A StepExecution represents a single attempt to run one of these specific steps.

Every time a step runs, a new StepExecution is created and bound to the parent JobExecution. This object is incredibly rich in telemetry data. As your chunk-oriented processes run, the StepExecution actively increments internal counters in real-time.

Metrics Tracked by StepExecution:

  • Read Count: The exact number of items successfully extracted by the ItemReader.
  • Write Count: The number of items successfully persisted by the ItemWriter.
  • Filter Count: The number of items discarded by your ItemProcessor returning null.
  • Skip/Rollback Count: The number of transient failures or chunk rollbacks triggered by fault-tolerance configurations.

4. JobRepository: The Metadata Brain

None of the state management, metric tracking, or restartability we discussed above is possible without the JobRepository. The repository is the core persistence mechanism (typically backed by a relational database like PostgreSQL, MySQL, or Oracle) that Spring Batch uses to memorize its state.

When you enable Spring Batch, it expects several schema tables to exist in your database (such as BATCH_JOB_INSTANCE, BATCH_JOB_EXECUTION, and BATCH_STEP_EXECUTION). Every time a job starts, a step commits a chunk, or an error occurs, the framework issues synchronous SQL updates to these tables.

This transactional persistence is what allows Spring Batch to safely resume a job that crashed on record 500,000 out of 1,000,000 without starting completely over. 


@Configuration
@EnableBatchProcessing
public class BatchConfig {

  // The JobRepository is automatically wired into the environment 
  // by Spring Boot when a DataSource is present.
  @Bean
  public Step sampleStep(JobRepository jobRepository, 
                         PlatformTransactionManager transactionManager) {
      return new StepBuilder("sampleStep", jobRepository)
              .tasklet(myTasklet(), transactionManager)
              .build();
  }
}

5. JobLauncher: The Execution Trigger

Finally, we have the JobLauncher. This component acts as the interface between your external triggers (like a REST controller, a Quartz scheduler, or a command-line runner) and the internal Spring Batch ecosystem.

When you invoke jobLauncher.run(job, parameters), the launcher takes over. It validates the parameters, queries the JobRepository to check for previous executions, orchestrates the creation of new JobExecution contexts, and ultimately delegates the processing thread to the job itself.

Conclusion: The Complete Execution Flow

To summarize, when a batch process is triggered, the framework follows a strict lifecycle choreography:

  1. An external event calls jobLauncher.run(job, parameters).
  2. The launcher consults the JobRepository to find an existing JobInstance for those parameters, or creates a new one.
  3. A new JobExecution is instantiated to represent this physical attempt.
  4. The Job begins executing its steps in order. For each step, a StepExecution is created.
  5. Throughout the chunk processing, metrics (reads, writes, skips) are continuously synchronized back to the JobRepository.
  6. Upon completion (or failure), the final statuses are persisted, ensuring full auditability and restartability.

Understanding this hierarchy is the foundational step toward building reliable, fault-tolerant batch architectures that can withstand the demands of production enterprise environments.


🧱 Spring Batch Core Components in Real Projects

Once you understand the core components of Spring Batch, explore these hands-on tutorials to see how jobs, steps, readers, processors, and writers work together in real-world scenarios.

📂 Read Multiple CSV Files

See how ItemReader implementations handle multiple input resources.

📥 CSV to Database

End-to-end batch pipeline using ItemReader, ItemProcessor, and ItemWriter.

🔄 ItemProcessor Example

Apply validation, transformation, and business rules during processing.

📤 Export Data to CSV

Understand ItemWriter behavior by exporting processed data.

🚫 Skip Policy & Error Handling

Configure fault-tolerant jobs using skip and error-handling strategies.

🔁 Retry Mechanism

Handle transient failures with retry and backoff configurations.

🔀 Conditional Flow in Jobs

Control job execution paths based on step exit statuses.

🧵 Multithreaded Step

Improve performance with parallel step execution.

⚙️ Tasklet

Use Tasklet-based steps for custom or non-chunk processing.

👂 JobExecutionListener

Track job and step lifecycle events using listeners.