<step id="step3" parent="loadTransactionFile"/>
<step id="batchStep" parent="runBatch"/>
In Listing 4-49, you identify two separate flows: one that loads two files and one that loads one file.
Each of these flows is executed in parallel. After all three steps ( step1 , step2 , and step3 ) have completed,
Spring Batch executes batchStep .
That's it. It's amazing how simple it is to do basic parallelization using Spring Batch, as this example
shows. And given the potential performance boosts, 7 you can begin to see why Spring Batch can be a
very effective tool in high-performance batch processing.
Later chapters cover a variety of error-handling scenarios including error handling at the entire job
level down to errors at the transaction level. But because steps are all about processing chunks of items,
the next topic is some of the error-handling strategies available when processing a single item.
Item Error Handling
Spring Batch 2 is based on the concept of chunk-based processing. Because chunks are based on
transaction-commit boundaries, the topic discusses how to handle errors for chunks when it covers
transactions in the ItemReader and ItemWriter chapters. However, individual items are usually the cause
of an error, and Spring Batch provides a couple of error-handling strategies at the item level for your use.
Specifically, Spring Batch lets you either skip the processing of an item or try to process an item again
after a failure.
Let's start by looking at retrying to process an item before you give up on it via skipping.
When you're processing large amounts of data, it isn't uncommon to have errors due to things that don't
need human intervention. If a database that is shared across systems has a deadlock, or a web service
call fails due to a network hiccup, stopping the processing of millions of items is a pretty drastic way to
handle the situation. A better approach is to allow your job to try to process a given item again.
There are three ways to implement retry logic in Spring Batch: configuring retry attempts, using
RetryTemplate , and using Spring's AOP features. The first approach lets Spring Batch define a number of
allowed retry attempts and exceptions that trigger the new attempt. Listing 4-50 show the basic retry
configuration for an item when a RemoteAccessException is thrown in the course of executing the
7 Not all parallelization results in an increase in performance. Under the incorrect situations, executing
steps in parallel can negatively affect the performance of your job.