Spring Batch - Spring Enterprise Recipes: A Problem Solution Approach - page 368

Items read from an ItemReader are normally aggregated. If a commit on the ItemWriter fails, the
aggregated items are kept and then resubmitted. This process is efficient and works most of the time.
One place where it breaks semantics is when reading from a transactional message queue. Reads from a
message queue can and should be rolled back if the transaction they participate in (in this case, the
transaction for the writer ) fails:
<tasklet transaction-manager="customTransactionManager" >
<chunk
reader="jmsItemReader" is-reader-transactional-queue="true"
processor="userRegistrationValidationProcessor"
writer="jdbcItemWriter"
commit-interval="5" />
</tasklet>
Rollbacks
Handling the simple case (“read X items and then, every Y items commit a database transaction every
Y items”) is easy. Spring Batch excels in the robustness it surfaces as simple configuration options for the
edge and failure cases.
If a write fails on an ItemWriter , or some other exception occurs in processing, Spring Batch will roll
back the transaction. This is valid handling for a majority of the cases. There may be some scenarios
when you want to control which exceptional cases cause the transaction to roll back.
You can use the no-rollback-exception-classes element to configure this for the step . The value is
a list of Exception classes that should not cause the transaction to roll back:
<step id = "step2">
<tasklet>
<chunk reader="reader" writer="writer" commit-interval="10" />
<no-rollback-exception-classes>
com.yourdomain.services.exceptions.ZipCodeNotZipPlusFiveCompliantException,
com.yourdomain.services.exceptions.CustomerNotFoundException
</no-rollback-exception-classes>
</tasklet>
</step>
9-8. Retry
Problem
You are dealing with a requirement for functionality that may fail but is not transactional. Perhaps it is
transactional but unreliable. You want to work with a resource that may fail when you try to read from or
write to it. It may fail because of networking connectivity because an endpoint is down or for any other
number of reasons. You know that it will likely be back up soon, though, and that it should be retried.
Solution
Use Spring Batch's retry capabilities to systematically retry the read or write.