Spring Boot 4 Complete Guide · 강의

작업, 단계 및 JobRepository 모델

실행 추적을 위한 작업, 단계 및 메타데이터 영속성으로 일괄 처리 작업을 구조화합니다.

작업, 단계 및 JobRepository 모델은(는) CoddyKit의 무료 Spring Boot 4 Complete Guide 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Spring Boot 4 Complete Guide 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Spring Batch Exists

Many real-world workloads are not request/response: nightly invoice generation, CSV imports, report exports, data migrations. These run as batch jobs processing large volumes of records.

They must be restartable after a crash.
They must track progress so you know what already ran.
They must handle millions of rows without loading everything into memory.

Spring Batch gives you a structured model for exactly this. The three core abstractions you must understand first are the Job, the Step, and the JobRepository.

The Job: A Unit of Work

A Job is the top-level container for an entire batch process. It has a name and is composed of one or more ordered Step instances.

One Job definition can be executed many times — each run is a JobInstance.
Each attempt at running a JobInstance is a JobExecution (status, start time, exit code).

In Spring Boot 4 you build a Job with a JobBuilder, supplying a name and a JobRepository.

@Bean
public Job importInvoicesJob(JobRepository jobRepository, Step readStep) {
    return new JobBuilder("importInvoicesJob", jobRepository)
            .start(readStep)
            .build();
}

JobInstance vs JobExecution

This distinction is the heart of restartability. Suppose you run importInvoicesJob for the date 2026-06-10.

The JobInstance is identified by the job name plus its identifying job parameters (here, the date). Re-running with the same date refers to the same instance.
Each run produces a new JobExecution. If the first attempt fails and you restart, you get a second JobExecution for the same JobInstance.

A completed JobInstance cannot be run again with the same identifying parameters — Spring Batch throws JobInstanceAlreadyCompleteException. This prevents accidental double-processing.

The Step: A Phase of the Job

A Step is an independent, sequential phase of a Job. A Job typically chains several steps: validate input, then process records, then send a summary email.

There are two flavors of step:

Chunk-oriented: read–process–write in configurable chunks. Ideal for large data sets.
Tasklet: a single arbitrary action (delete a file, run a stored procedure, ping a service).

Each Step run is tracked by a StepExecution, which records read/write counts, commit count, and status.

A Chunk-Oriented Step

A chunk-oriented step ties together an ItemReader, an optional ItemProcessor, and an ItemWriter. The chunk(n, transactionManager) call sets the commit interval: after every n items are read and processed, the writer flushes and the transaction commits.

Smaller chunks mean more frequent commits (safer restart point, more overhead); larger chunks mean fewer commits (faster, but more work lost on rollback).

@Bean
public Step readStep(JobRepository jobRepository,
                     PlatformTransactionManager txManager,
                     ItemReader<Invoice> reader,
                     ItemProcessor<Invoice, Invoice> processor,
                     ItemWriter<Invoice> writer) {
    return new StepBuilder("readStep", jobRepository)
            .<Invoice, Invoice>chunk(100, txManager)
            .reader(reader)
            .processor(processor)
            .writer(writer)
            .build();
}

A Tasklet Step

When a phase is a single action rather than a stream of items, use a Tasklet. The execute method returns RepeatStatus.FINISHED when done, or CONTINUABLE to be called again.

Tasklets are perfect for setup/cleanup steps such as archiving a processed file or truncating a staging table.

@Bean
public Step cleanupStep(JobRepository jobRepository,
                        PlatformTransactionManager txManager) {
    return new StepBuilder("cleanupStep", jobRepository)
            .tasklet((contribution, chunkContext) -> {
                Path staging = Path.of("/data/staging.csv");
                Files.deleteIfExists(staging);
                return RepeatStatus.FINISHED;
            }, txManager)
            .build();
}

Composing Steps Into a Job

Steps run in the order you declare them. Use start(...) for the first step and next(...) to chain the rest. By default, the Job stops if a Step ends with status FAILED.

Here the job validates, imports, then cleans up. If the import step fails, cleanupStep does not run, and on restart the job resumes from the failed step.

@Bean
public Job invoiceJob(JobRepository jobRepository,
                      Step validateStep, Step readStep, Step cleanupStep) {
    return new JobBuilder("invoiceJob", jobRepository)
            .start(validateStep)
            .next(readStep)
            .next(cleanupStep)
            .build();
}

The JobRepository: Persistent Memory

The JobRepository is the component that persists all batch metadata: which JobInstances exist, their JobExecutions, each StepExecution, and the execution contexts.

It is how Spring Batch knows a job already completed.
It is how a restart figures out where to resume.
It stores read/write/commit counts for monitoring.

By default it writes to a relational database using a set of BATCH_* tables. Without a working JobRepository there is no restartability and no execution history — it is not optional.

The BATCH_ Metadata Tables

The JobRepository persists into a fixed schema. The key tables are:

BATCH_JOB_INSTANCE — one row per JobInstance (name + identity hash).
BATCH_JOB_EXECUTION — one row per run attempt, with status and exit code.
BATCH_STEP_EXECUTION — per-step counters (read/write/skip counts).
BATCH_JOB_EXECUTION_CONTEXT / BATCH_STEP_EXECUTION_CONTEXT — serialized state used to resume.
BATCH_*_SEQ — sequences for primary keys.

Spring Boot ships the DDL and can create these automatically. The property below initializes the schema on startup.

# application.properties
spring.batch.jdbc.initialize-schema=always
# Prevent jobs from auto-running on app startup
spring.batch.job.enabled=false

Launching a Job

You execute a Job through a JobLauncher, passing JobParameters. Identifying parameters define the JobInstance; here the run date makes each day a distinct instance.

The launcher returns a JobExecution whose status (COMPLETED, FAILED, STOPPED) reflects the run. All of this is recorded in the JobRepository.

@Component
public class InvoiceJobRunner {
    private final JobLauncher jobLauncher;
    private final Job invoiceJob;

    public InvoiceJobRunner(JobLauncher jobLauncher, Job invoiceJob) {
        this.jobLauncher = jobLauncher;
        this.invoiceJob = invoiceJob;
    }

    public void run(LocalDate date) throws Exception {
        JobParameters params = new JobParametersBuilder()
                .addLocalDate("runDate", date)
                .toJobParameters();
        JobExecution execution = jobLauncher.run(invoiceJob, params);
        System.out.println("Status: " + execution.getStatus());
    }
}

How Restart Uses the Repository

Put the pieces together. When a Job fails mid-run:

The failed JobExecution is marked FAILED, but its JobInstance is not marked complete.
Each completed Step is recorded; a chunk-oriented step also saved how many items it processed in its ExecutionContext.
Re-launching with the same identifying parameters creates a new JobExecution on the same instance. Spring Batch skips already-completed steps and resumes the failed step from the last committed chunk.

This is why identifying parameters and the JobRepository must be stable: they are the coordinates of resumption.

Quick Check

Test your understanding of the job/instance/execution model.

Recap

You now have the structural model of Spring Batch:

Job — the top-level process, built with JobBuilder, composed of ordered Steps.
JobInstance vs JobExecution — an instance is identified by name + identifying parameters; each run attempt is a separate execution.
Step — a phase, either chunk-oriented (read/process/write with a commit interval) or a tasklet (single action); tracked by a StepExecution.
JobRepository — persistent metadata in the BATCH_* tables that powers restartability, resume logic, and monitoring.

Master these and the rest of Spring Batch — readers, writers, listeners, partitioning — slots neatly on top.

자주 묻는 질문

“작업, 단계 및 JobRepository 모델” 강의는 무료인가요?

네 — “작업, 단계 및 JobRepository 모델” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Spring Boot 4 Complete Guide 강의 전체를 잠금 해제할 수 있습니다. Spring Boot 4 Complete Guide 강의에는 총 4개의 강의가 포함되어 있습니다.

“작업, 단계 및 JobRepository 모델”에서 뭘 배우나요?

실행 추적을 위한 작업, 단계 및 메타데이터 영속성으로 일괄 처리 작업을 구조화합니다. 브라우저에서 직접 실행하는 실습 코드로 Spring Boot 4 Complete Guide을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Spring Boot 4 Complete Guide을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Spring Boot 4 Complete Guide은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.

“작업, 단계 및 JobRepository 모델” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Spring Boot 4 Complete Guide 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Spring Boot 4 Complete Guide 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Spring Boot 4 Complete Guide(으)로 돌아가기