RepositoryItemWriter does not flush batch

[fmbenhassine]

Discussed in #5034

^{Originally posted by Walnussbaer October 17, 2025}
Simple question: why is there even a RepositoryItemWriter based on CrudRepository?

It does not make sense to me, because CrudRepository does not provide the saveAllAndFlush method.

So to me this ItemWriter is not compatible with the rollback logic of Spring Batch. How shall Spring Batch know when to rollback if the flush is happening outside of the actual step? If something goes wrong flushing the data to the database, the writer has already returned, so Spring Batch cannot rollback the transaction and repeat the chunk.

Is this intended behaviour and do I get something wrong?

Any helpful answer is appreciated.

Also, https://docs.spring.io/spring-batch/docs/4.3.8/reference/html/readersAndWriters.html#itemWriter states the following:

After writing out the list, any flushing that may be necessary can be performed before returning from the write method. For example, if writing to a Hibernate DAO, multiple calls to write can be made, one for each item. The writer can then call flush on the hibernate session before returning.

[fmbenhassine]

The flush is done during the commit, and indeed, if the commit fails, an OLFE is thrown and the state is corrupted (there is an old known issue for this, see #1826, which I attempted to fix many years ago #591 (comment), but I gave up because the current implementation of the chunk-oriented step was not straightforward to update, see #3950 ).

Like the documentation mentions, the recommendation is to perform the flush in the writer (see #1826 (comment) as well). For example, the JpaItemWriter does that, and so should the RepositoryItemWriter. So your concern is valid and I think we need to update it to use an interface that has a saveAllAndFlush method, like org.springframework.data.jpa.repository.JpaRepository#saveAllAndFlush(Iterable<S> entities).