Transaction rollback issue for skippable exception migrating to spring batch 6

[sjoerd-vogel]

We have a setup where we intentionally skip constraint violations during inserts. We use a chunked step configured like so

        return StepBuilder("myJobStep", jobRepository)
            .chunk<Input, Output>(chunkSize)
            .transactionManager(transactionManager)
            .reader(reader)
            .processor(processor)
            .writer(writer)
            .faultTolerant()
            .skip(DataIntegrityViolationException::class.java)
            .skipLimit(Long.MAX_VALUE)
            .listener(skipListener)
            .listener(stepExecutionListener)
            .listener(executionContextPromotionListener)
            .build()

It is supposed to skip items upon database constraint violations, hence the exception type configures in the 'skip'. However after migrating to spring batch 6 (spring boot 4), this skipping no longer works and I get:

org.springframework.core.retry.RetryException: Retry policy for operation 'Retryable write operation' exhausted; aborting execution

Caused by: org.springframework.dao.DataIntegrityViolationException: could not execute statement [Unique index or primary key violation:

Caused by: org.h2.jdbc.JdbcSQLIntegrityConstraintViolationException

A bit further on it logs:

org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only

Our writer does a saveAll() on a JPA repository like this:

class Writer (private val myDAO: MyDAO): ItemWriter<Output> {
    override fun write(chunk: Chunk<out Output>) {
        myDAO.saveAll(chunk.toList())
    }
}

Seems to me like the exception thrown is marking the transaction as rollback-only before the skip configuration has any chance of skipping the item. All of this worked before the migration. Please advice on how to proceed.

[sjoerd-vogel]

Ok, it seems like adding @Transactional(propagation = Propagation.REQUIRES_NEW) on the saveAll does the job. Can anyone provide some insight into why this is needed now and and if this is a good approach?

[fmbenhassine]

Adding that annotation is not needed, see #5303 (comment)

[fmbenhassine]

This was actually a regression in v6 which has been fixed in #5210. The fix will be shipped in the upcoming 6.0.3.

[fmbenhassine]

I'm closing this discussion for now, but if you need further support, please do not hesitate to add a comment here. Thank you.

[sjoerd-vogel]

Turns out I had set the chunksize 1 by mistake while testing. Setting it to something higher breaks it again (StaleObjectStateException).

To get it to work, it seems I need to persist items one by one (in their own transactions). Meaning, adding the annotation mentioned earlier as well as either

set chunksize to 1

or

Replace saveAll(chunk) with chunk.forEach(::save)

This still seems to be the case on 6.0.3 (version overridden in spring boot 4.0.3).

[fmbenhassine]

@sjoerd-vogel Thank you for taking the time to prepare these reproducers! I will take a look and get back to you asap.

[sjoerd-vogel]

@fmbenhassine no problem at all. Thank you for the assist.

[sjoerd-vogel]

Let me know if there is anything I can do to help. I dont mind getting my hands dirty, I just wouldn't know where to start.

[fmbenhassine]

I checked your samples, thank you for preparing them. This is a configuration problem, not a runtime problem. In fact, the use case works as expected with a JDBC setup (that is the first thing I wanted to verify). Here is the JDBC sample (it shows that only the item that violates the constraint is skipped as expected):

demo6-jdbc-gh5303.zip

In demo6, the project uses JPA, but the batch infrastructure is based on JDBC (which is the default configuration that boot sets up in the JDBC starter). When using JPA, Spring Batch should be configured with a JpaTransactionManager, otherwise batch artefacts will not participate in the same transaction as the one driven by Spring Batch, which is basically the issue here: Caused by: org.hibernate.StaleObjectStateException: Row was already updated or deleted by another transaction for entity.

The next step is checking if the sample works with a JPA-based batch infrastructure (plain Spring Batch, no Boot involved to make sure it is not an auto-configuration problem). If that works as expected, it would mean the current JDBC starter of Boot is not suitable for a JPA use case, in which case we might need a new Boot starter for JPA.

Let me know if there is anything I can do to help. I dont mind getting my hands dirty, I just wouldn't know where to start.

Thank you for your help! I will check what I mentioned earlier and get back to you asap, but you can help if you want investigate the JPA setup.

[sjoerd-vogel]

Ah, ok this was not at all a clear distinction to me. We use JPA for the most part. So it makes sense I should configure it for that purpose. I will have a closer look later today. Thank you for the effort.

edit
I presume it makes sense to remove the jdbc starter then. For the JPA setup?

edit 2
I notice with or without the jdbc starter, the injected transactionmanager is the jpa one.

edit3
I just re-read your comment and noticed the remark about using spring batch without spring boot. I will investigate.

[fmbenhassine]

Re-opening the discussion to investigate the JPA setup.

[sjoerd-vogel]

I created a demo6 flavor without spring boot and it seems to be failing in the same way, suggesting it is not an issue with autoconfig.
demo6-non-boot.zip

Hibernate: insert into MYTABLE (THING,id) values (?,default)
Apr 09, 2026 1:59:54 PM org.hibernate.engine.jdbc.spi.SqlExceptionHelper logExceptions
WARN: HHH000247: ErrorCode: 23505, SQLState: 23505
Apr 09, 2026 1:59:54 PM org.hibernate.engine.jdbc.spi.SqlExceptionHelper logExceptions
WARN: Unique index or primary key violation: "PUBLIC.THING_UNIQ INDEX PUBLIC.THING_UNIQ_INDEX_8 ON PUBLIC.MYTABLE(THING NULLS FIRST) VALUES ( /* 1 */ 'bla1' )"; SQL statement:
insert into MYTABLE (THING,id) values (?,default) [23505-240]
Hibernate: select mt1_0.id,mt1_0.THING from MYTABLE mt1_0 where mt1_0.id=?
Hibernate: select mt1_0.id,mt1_0.THING from MYTABLE mt1_0 where mt1_0.id=?

expected: <COMPLETED> but was: <FAILED>
Comparison Failure: 
Expected :COMPLETED
Actual   :FAILED

[fmbenhassine]

Thank you for checking. This seems like a bug in Spring Batch. I created #5377 and planned it for the next patch release (I modified your sample to the bare minimum to isolate the issue).

I am closing this discussion as it is not a migration issue anymore, but rather a bug in Spring Batch that we need to fix.

That said, and I will leave this here, working with JPA has been a frustrating experience for me over the years. I gave up on that spec long ago, especially in the context of batch processing (due to several issues: poor performance even with caching and all best practices in place, lazy loading issues, the requirement for specific transaction setup for things to work, etc).

[sjoerd-vogel]

I totally get what you are saying. I have been falling out of love with JPA myself. However, right now, it does not make sense for us to migrate away from JPA. Thank you for all the help. I am not familiar with the spring (batch) codebase, but this seems like a great opportunity for me to learn more. I will keep an eye on the bug tracker.