5.5 KiB
8. Restart reruns only the failed partition — proved, not assumed
← Previous | README | Next: JobExecutionAlreadyRunningException, and recover →
The reference documentation states that a restarted partitioned step only re-executes partitions
that did not complete. This chapter is that claim, checked against a real BATCH_STEP_EXECUTION
table rather than taken on faith — using exactly the stuck job from
chapter 7, after
chapter 9's recovery step unsticks it.
The evidence
$ java -cp h2-2.4.240.jar org.h2.tools.Shell -url jdbc:h2:file:./data/rejecttest -user sa -password "" \
-sql "SELECT JOB_EXECUTION_ID, STEP_EXECUTION_ID, STEP_NAME, STATUS, READ_COUNT
FROM BATCH_STEP_EXECUTION WHERE JOB_EXECUTION_ID IN (1,33) ORDER BY JOB_EXECUTION_ID, STEP_EXECUTION_ID;"
JOB_EXECUTION_ID | STEP_EXECUTION_ID | STEP_NAME | STATUS | READ_COUNT
1 | 1 | ordersManagerStep | FAILED | 5000
1 | 2 | ordersWorkerStep:partition3 | FAILED | 0
1 | 3 | ordersWorkerStep:partition2 | FAILED | 0
1 | 4 | ordersWorkerStep:partition1 | COMPLETED | 5000
1 | 5 | ordersWorkerStep:partition0 | FAILED | 0
33 | 33 | ordersManagerStep | COMPLETED | 15000
33 | 34 | ordersWorkerStep:partition3 | COMPLETED | 5000
33 | 35 | ordersWorkerStep:partition2 | COMPLETED | 5000
33 | 36 | ordersWorkerStep:partition0 | COMPLETED | 5000
33 | 37 | reportStep | COMPLETED | 0
Full transcript: docs/output/08-recover-then-restart.txt.
JobExecution 33 — the restart — has exactly three new worker StepExecution rows:
partition3, partition2, partition0, the three chapter 9's
recovery step marked FAILED. There is no new row for partition1. It stayed COMPLETED from
JobExecution 1, at READ_COUNT 5000, untouched. ordersManagerStep's own READ_COUNT for
execution 33 is 15000 — the sum of the three re-run partitions, not all four.
Why this works: partition names are stable across attempts
MultiResourcePartitioner names partitions partition0, partition1, ... in the order its
resources array iterates (chapter 3), and that order is
deterministic once the shard files and their sort order are fixed — BatchConfig.partitioner()
explicitly sorts resources by filename before handing them to MultiResourcePartitioner for
exactly this reason. Restart resolves each partition's StepExecution by that stable name against
the same JobInstance, the same mechanism the earlier spring-batch module
demonstrated for a single, unpartitioned step: same identifying job parameters, same instance,
already-COMPLETED steps skipped. Partitioning does not add a different restart mechanism; it
applies the same one once per partition.
Going deeper
- Ordinary (unpartitioned) restart semantics, which this chapter's mechanism is not different from: Spring Batch on Boot 4.1, chapter 7.
- Why
JobExecution1 needed a recovery step before this restart was even possible: chapter 9.