Fix optimistic locking and add interruption check in ChunkOrientedStep by KILL9-NO-MERCY · Pull Request #5165 · spring-projects/spring-batch

KILL9-NO-MERCY · 2025-12-15T13:33:12Z

Problem

As reported in issue #5114, after commit e5fbc2a, StepExecution.terminateOnly is not being set properly after JobOperator.stop().

Additionally, the JobRepository.update(StepExecution) call introduced in e5fbc2a (via JobRepository.stop()) causes OptimisticLockingFailureException during step execution, as reported in #5120.

However, commit e5fbc2a must be retained for d4a7dfd to graceful shutdown function correctly.

Solution

1. Improved JobRepository.update(StepExecution)

Removed:

Legacy job stop check (jobExecution.isStopping()) used in older versions (in previous versions, JobOperator.stop() only cause the JobExecution status to STOPPING)

Added:

New Batch 6 style stop detection by checking StepExecution state from database
Fetch latest StepExecution from database and check if isStopped()
If externally stopped, synchronize version and set stepExecution.setTerminateOnly()

This approach prevents OptimisticLockingFailureException by synchronizing the StepExecution version with the latest database state before update.

2. Added JobRepository.update() in ChunkOrientedStep

Unlike TaskletStep which calls JobRepository.update(stepExecution) after processing each chunk, ChunkOrientedStep was missing this call. This prevented it from fetching the latest StepExecution version and JobExecution status (BatchStatus = STOPPED) from the batch metadata repository.

Added JobRepository.update(stepExecution) in the same location as TaskletStep to ensure both step implementations can synchronize with the latest state from the database.

New commit: Updated interruption detection logic

The first implementation of this PR checked latestStepExecution.isStopped(), which failed in multi-step jobs when JobOperator.stop() was called between steps:

First step completes
JobOperator.stop() called
Second step's StepExecution not yet created
No way to detect the stop signal

So Changed to check latestStepExecution.getJobExecution().isStopped() instead:

Changes

SimpleJobRepository.update(StepExecution)

Fetch latest StepExecution from database before update
Check if the fetched JobExecution(of latest StepExecution) is in STOPPED status
Synchronize current StepExecution's version with database latest state
Set terminateOnly flag when externally stopped

ChunkOrientedStep

Added getJobRepository().update(stepExecution) call in finally block after each chunk processing
Matches TaskletStep behavior for consistent interruption handling
Ensures step can detect job stop signals by fetching latest state from database

Related Issues

Fixes gh-5120
See gh-5114
Related to e5fbc2a, d4a7dfd

KILL9-NO-MERCY · 2025-12-15T13:41:36Z

 	public void update(StepExecution stepExecution) {
 		stepExecution.setLastUpdated(LocalDateTime.now());
-		if (this.jobExecution != null && this.jobExecution.isStopping()) {
+		if (stepExecution.isStopped()) {


In ResourcelessJobRepository (in-memory implementation), when JobOperator.stop() calls Repository.update(stepExecution), the fetched StepExecution is actually the same instance as the one being updated (since everything is in memory). Therefore, checking stepExecution.isStopped() directly reflects the state set by the stop operation.

Please let me know if I'm missing anything or if there's a better approach for this.

KILL9-NO-MERCY · 2025-12-15T13:45:55Z


 		stepExecution.setLastUpdated(LocalDateTime.now());
+
+		StepExecution latestStepExecution = getStepExecution(stepExecution.getId());


Fetch latest StepExecution from database and synchronize version to prevent OptimisticLockingFailureException.

In Batch 6, JobOperator.stop() updates StepExecution status to STOPPED (unlike Batch 5 which only set JobExecution to STOPPING). Therefore, instead of calling jobExecutionDao.synchronizeStatus(), we now:

Call getStepExecution() to get the latest state

Synchronize status and version if stopped externally

Set terminateOnly flag

This ensures version consistency between concurrent stop and execution threads.

KILL9-NO-MERCY · 2025-12-15T13:51:48Z

 			stepExecution.apply(contribution);
 			this.compositeItemStream.update(stepExecution.getExecutionContext());
 			getJobRepository().updateExecutionContext(stepExecution);
+			getJobRepository().update(stepExecution);


Added getJobRepository().update(stepExecution) call to match TaskletStep behavior (line #464).

This ensures ChunkOrientedStep checks for job interruption signals after each chunk processing, just like TaskletStep does. Without this call, ChunkOrientedStep cannot fetch the latest StepExecution state from the database and will miss stop signals from JobOperator.stop().

If the removal of this update() call in ChunkOrientedStep was intentional in the past, then at minimum, there should be alternative logic to synchronize the status and version from the latest StepExecution (required for proper job stop handling).

Please let me know if there's a specific reason this call was omitted or if a different synchronization approach is preferred.

When JobOperator.stop() is called, the StepExecution version could become out of sync between the stopping thread and the executing step thread, causing OptimisticLockingFailureException. This commit synchronizes the StepExecution version by fetching the latest state from the batch metadata before update. If the recent StepExecution is in STOPPED status, it upgrades the current StepExecution's status and version to match the database state, preventing version conflicts. Additionally, added JobRepository.update() call in ChunkOrientedStep after each chunk to match TaskletStep behavior. This ensures both step implementations properly check for job interruption signals by synchronizing with the latest StepExecution status from the database. Fixes spring-projectsgh-5120 Signed-off-by: kill9-no-mercy <[email protected]>

…etection Previously, the interruption check used StepExecution.isStopped() which fails when a job is stopped between steps (after first step completes but before second StepExecution is created). Changed to check JobExecution.isStopped() instead, which correctly detects job stop signals regardless of the current step state. This ensures proper interruption handling for multi-step jobs. See spring-projectsgh-5114 See spring-projectsgh-5120 Signed-off-by: kill9-no-mercy <[email protected]>

fmbenhassine · 2025-12-15T15:28:02Z

Hi @KILL9-NO-MERCY ,

Thank you for the PR 🙏 This change set adds the missing database sync which I mentioned here: #5114 (comment), which is great! I tested the shutdown sample with this PR and in fact it fixes it.

However, there are indeed some side effects / regressions from this PR (see failing tests in ChunkOrientedStepIntegrationTests and ChunkOrientedStepFaultToleranceIntegrationTests when building the project on the latest main 98c10cd). Can you please check? If we manage to have a fix without a regression, it will be good to merge for the upcoming v6.0.1.

Many thanks upfront.

Move stepExecution.update() outside chunk transaction to prevent version mismatch when transaction rolls back. Problem: - Chunk transaction rollback reverts DB version but leaves in-memory version incremented - Next update() causes OptimisticLockingFailureException Solution: - Call getJobRepository().update(stepExecution) after transaction completes, outside transactionTemplate.executeWithoutResult() - On success: update() is called with synchronized versions - On failure: update() is skipped, preventing version conflict Signed-off-by: kill9-no-mercy <[email protected]>

KILL9-NO-MERCY · 2025-12-15T17:45:35Z

@fmbenhassine
Hi Mahmoud

Thanks for catching the integration-test oversight!

I investigated the root cause and found that JobRepository.update() should NOT be called when chunk processing fails. However, it was placed in the finally block, causing it to execute even on failures. This led to a version mismatch between the in-memory StepExecution (version incremented) and the database StepExecution (version rolled back due to transaction rollback).

The fix moves the update() call outside the transaction block, ensuring it's only called when no exceptions occur.

Changes:

Moved getJobRepository().update(stepExecution) to doExecute() method, outside transactionTemplate.executeWithoutResult()
Removed update() from processNextChunk() finally block
Update is now only called on successful chunk processing

fmbenhassine · 2025-12-16T00:05:42Z

Thank you very much for the update! That was it, two birds with one stone 🎉

Rebased and merged as 644d7e6. Thank you for your contribution, much appreciated 🙏

KILL9-NO-MERCY force-pushed the kill9/GH-5120 branch 2 times, most recently from 78ba896 to 0feafa1 Compare December 15, 2025 13:37

KILL9-NO-MERCY commented Dec 15, 2025

View reviewed changes

Comment thread spring-batch-core/src/main/java/org/springframework/batch/core/step/StoppableStep.java

KILL9-NO-MERCY commented Dec 15, 2025

View reviewed changes

This was referenced Dec 15, 2025

StepExecution Update in SimpleJobOperator.stop() Causes JobExecution.BatchStatus.UNKNOWN after graceful stop #5120

Closed

stop() does not prevent upcoming steps to be executed anymore #5114

Closed

KILL9-NO-MERCY force-pushed the kill9/GH-5120 branch from 0feafa1 to f62da2b Compare December 15, 2025 14:06

KILL9-NO-MERCY force-pushed the kill9/GH-5120 branch from d58bdbc to 5a0c284 Compare December 15, 2025 17:38

KILL9-NO-MERCY force-pushed the kill9/GH-5120 branch from 5a0c284 to bd7285f Compare December 15, 2025 17:40

fmbenhassine closed this Dec 16, 2025

KILL9-NO-MERCY mentioned this pull request Jan 6, 2026

ChunkOrientedStep#doExecute updates the StepExecution outside of the chunk transaction boundary. #5199

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix optimistic locking and add interruption check in ChunkOrientedStep#5165

Fix optimistic locking and add interruption check in ChunkOrientedStep#5165
KILL9-NO-MERCY wants to merge 3 commits intospring-projects:mainfrom
KILL9-NO-MERCY:kill9/GH-5120

KILL9-NO-MERCY commented Dec 15, 2025 •

edited

Loading

Uh oh!

KILL9-NO-MERCY Dec 15, 2025

Uh oh!

KILL9-NO-MERCY Dec 15, 2025 •

edited

Loading

Uh oh!

Uh oh!

KILL9-NO-MERCY Dec 15, 2025

Uh oh!

fmbenhassine commented Dec 15, 2025

Uh oh!

KILL9-NO-MERCY commented Dec 15, 2025

Uh oh!

fmbenhassine commented Dec 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants


		stepExecution.setLastUpdated(LocalDateTime.now());

		StepExecution latestStepExecution = getStepExecution(stepExecution.getId());

Conversation

KILL9-NO-MERCY commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

1. Improved JobRepository.update(StepExecution)

2. Added JobRepository.update() in ChunkOrientedStep

New commit: Updated interruption detection logic

Changes

SimpleJobRepository.update(StepExecution)

ChunkOrientedStep

Related Issues

Uh oh!

KILL9-NO-MERCY Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

KILL9-NO-MERCY Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

KILL9-NO-MERCY Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

fmbenhassine commented Dec 15, 2025

Uh oh!

KILL9-NO-MERCY commented Dec 15, 2025

Uh oh!

fmbenhassine commented Dec 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

KILL9-NO-MERCY commented Dec 15, 2025 •

edited

Loading

KILL9-NO-MERCY Dec 15, 2025 •

edited

Loading