إعادة التشغيل ومعالجة الأخطاء

Long batch jobs hit bad rows, transient network errors, and crashes. Spring Batch provides skip, retry and restartability so a job can survive and resume.

Because the JobRepository records each step execution, a failed job can be restarted and it resumes from where it stopped, not from the beginning. The same JobParameters must be used.

Relaunch with the same parameters and Spring Batch detects the prior failed execution and continues it. Completed steps are skipped.

Use a fault-tolerant step to skip records that throw a given exception, up to a limit, instead of failing the whole job.

The skipLimit caps how many skips are tolerated. Once exceeded, the step fails. This prevents a job from silently ignoring a flood of bad data.

For temporary failures (a deadlock, a brief network blip) use retry. The item operation is retried up to a limit before being skipped or failing.

You can chain both: retry transient exceptions a few times, and skip persistent ones. Order matters - retry first, then skip if retries are exhausted.

Listeners let you observe and log what was skipped or retried, which is essential for auditing batch runs.

On restart, already-committed chunks are not re-read, but your writes should still be idempotent where possible (use upserts or natural keys) so a partial run does not create duplicates.

Sometimes an exception should not roll back the chunk. Declare it with noRollback so processing continues without discarding the transaction.

A completed JobInstance cannot be re-run with the same parameters - Spring throws JobInstanceAlreadyCompleteException. Add a unique parameter (like a timestamp) when you truly want a fresh run.

Test your error-handling knowledge.

You made batch jobs resilient:

• Restartability resumes a failed job from the last good point
• skip + skipLimit tolerates bad data
• retry + retryLimit handles transient errors
• Listeners audit skips/retries; keep writes idempotent