Bug Description

This issue was originally raised in #5210. While #5210 focused on the duplicate data insertion problem, further testing revealed that
rollbackCount was also incorrect.

Problems Found

1. Duplicate data insertion - Scan mode executes in the same transaction as failed write
2. Incorrect rollbackCount - No rollback before scan → rollbackCount is not incremented

Steps to Reproduce

See #5210 for example projects comparing Spring Batch 5 and 6 behavior.

Expected Behavior

• Scan mode should execute in a new transaction after rollback (same as FaultTolerantChunkProcessor in Spring Batch 5)
• rollbackCount should reflect actual transaction rollbacks

Actual Behavior

Solution

Before (Bug)

[TX 1] write(1,2,3) → fail → scan(1,2,3) → commit
↑
item "1" written twice (duplicate!)

After (Fixed)

[TX 1] write(1,2,3) → fail → save state → ROLLBACK
↓
[TX 2] scan(1,2,3) → write each item → commit
↑
item "1" written once (correct!)

Key Changes

1. State management - Added scanMode and pendingChunk to ChunkTracker
2. Transaction separation - Re-throw exception to trigger rollback before scan
3. New transaction for scan - Execute scan in next iteration with clean transaction

Related

• Transaction is not rolled back before chunk scanning in ChunkOrientedStep with skip policy #5210 - Original issue reporting duplicate data