0

Configured the below in my project:

<batch:no-rollback-exception-classes>
        <batch:include class="java.sql.SQLException"/>
        <batch:include class="org.springframework.dao.DuplicateKeyException"/>
       <batch:include class="java.sql.SQLIntegrityConstraintViolationException"/>

</batch:no-rollback-exception-classes>

While loading the file, I have duplicate records, but since I have configured org.springframework.dao.DuplicateKeyException under no-rollback-exception-classes, Spring batch should not rollback the records, but still the records are getting rollbacked. If I remove the DuplicateKeyException from the list, then it is throwing the exception. We are using Spring batch version: 3.0.7.RELEASE

<batch:no-rollback-exception-classes>
        <batch:include class="java.sql.SQLException"/>
        <batch:include class="org.springframework.dao.DuplicateKeyException"/>
       <batch:include class="java.sql.SQLIntegrityConstraintViolationException"/>

</batch:no-rollback-exception-classes>

Records are not expected to rollback, but records are rollbacked.

Guillermo Cacheda
  • 2,162
  • 14
  • 23
sanjay
  • 89
  • 1
  • 7

1 Answers1

0

According to your configuration, when a DuplicateKeyException is thrown, Spring Batch will still try to commit the transaction (no rollback), but this commit will fail anyway due to that exception. Spring Batch can't force the database to commit records with duplicate keys or violating integrity constraints.

You need to filter out duplicate items with an ItemProcessor before sending them to the writer.

Mahmoud Ben Hassine
  • 28,519
  • 3
  • 32
  • 50
  • but atleast remaining records have to be inserted right? – sanjay Feb 11 '19 at 11:53
  • No, that is the idea of chunk processing: a chunk of items is processed as a unit, either all items are committed or none. However, there is an advanced feature of Spring Batch which is chunk "scanning". When the writer throws a **skippable** exception, Spring Batch cannot know which item in the chunk is the faulty one, so it will re-process/re-write items one by one (basically resets the chunk-size to 1) and do a commit per item (so only the transaction of the faulty item is rolled back). But this happens only when a **skippable** exception is thrown. Hope this helps. – Mahmoud Ben Hassine Feb 11 '19 at 12:11