Spring Batch块处理模式下事务回滚及重试机制问题咨询

Great question—this behavior is completely expected once you unpack how Spring Batch manages item state, transaction rollbacks, and retry logic, even if it feels counterintuitive at first. Let’s break it down step by step:

Why You’re Seeing Modified Values in Retries #

Here’s the core of what’s happening:

• Spring Batch doesn’t deep-copy items from the reader: When your JdbcItemReader fetches an item, it passes a reference to that object to your processor. If your processor modifies fields on that same object (instead of returning a new instance), those changes live in memory—transaction rollbacks don’t undo in-memory object modifications.
• Retry uses already-fetched items, not re-read originals: When the JPAItemWriter throws an exception and triggers a rollback, Spring Batch doesn’t go back to the reader to re-fetch the original items. The reader’s state (like a JDBC cursor or pagination offset) has already advanced past those items, and Spring Batch retains the in-memory collection of items it already pulled. When it switches to chunk size 1 for targeted retries, it’s reprocessing those same (already modified) object references, not fresh copies from the database.

Your specific scenario amplifies this: since your processor modifies a field that’s used in the reader’s WHERE clause, re-reading the original item isn’t even feasible at that point—the in-memory object’s value is altered, even though the database record remains unchanged. Retries end up processing this modified in-memory state instead of the original database value.

Is This "Normal"? #

Yes. This is how Spring Batch is designed to work by default. The framework prioritizes efficiency and avoids re-reading data unless explicitly configured to do so, and it doesn’t intervene in how you handle object state in your processor. The key gotcha here is forgetting that transaction rollbacks only affect database changes, not in-memory objects.

How to Fix or Mitigate This #

If you want consistent processing results during retries, you have a few solid options:

1. Return a New Object from Your Processor #

Instead of modifying the input item directly, create a new instance, copy all the original fields into it, then make your modifications on the new object. This way, the original item from the reader stays untouched, and retries will process the original state every time:

public class MyProcessor implements ItemProcessor<OriginalItem, ProcessedItem> {
    @Override
    public ProcessedItem process(OriginalItem originalItem) {
        ProcessedItem processedItem = new ProcessedItem();
        // Copy original fields to the new object
        processedItem.setId(originalItem.getId());
        processedItem.setOriginalField(originalItem.getOriginalField());
        // Modify the new object's fields as needed
        processedItem.setModifiedField(originalItem.getOriginalField() + "_modified");
        return processedItem;
    }
}

2. Reset Item State Before Retries #

If you must modify the input item (e.g., due to constraints in your model), you can save the original state of the affected fields before processing, then reset them in a retry listener. For example, use a RetryListener to capture the original value when processing starts, and restore it if a retry is triggered:

public class ItemResetListener implements RetryListener {
    private Map<Object, Object> originalFieldValues = new HashMap<>();

    @Override
    public <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
        // Restore original field value on the item
        MyItem item = (MyItem) context.getAttribute("currentItem");
        item.setAffectedField(originalFieldValues.get(item));
    }

    @Override
    public <T, E extends Throwable> boolean open(RetryContext context, RetryCallback<T, E> callback) {
        // Capture original field value before processing
        MyItem item = (MyItem) context.getAttribute("currentItem");
        originalFieldValues.put(item, item.getAffectedField());
        return true;
    }
}

Then register this listener with your step’s retry policy.

3. Use a Stateful Reader with Reset Capabilities #

While JdbcItemReader isn’t easily reset, if your use case allows, you could implement a custom reader that saves the state of the items it fetches (e.g., by caching original values) and can re-serve the original state when retries are needed. This is more complex but feasible for specific scenarios.

Wrap-Up #

The behavior you’re seeing is a natural consequence of Spring Batch’s approach to item handling and transaction management. The fix boils down to ensuring that retries process the original item state—either by using immutable processed items or resetting state manually.

内容的提问来源于stack exchange，提问作者Andrea