Listing 4-23 may look intimidating, but let's focus on the job and step configuration at the end. The
rest of the file is the configuration of a basic ItemReader and ItemWriter , which are covered in Chapters 7
and 9, respectively. When you look through the job in Listing 4-23, you see that the step begins with the
step tag. All that is required is the id or name, like any other Spring Bean. Within the step tag is a tasklet
tag. The org.springframework.batch.core.step.tasklet.Tasklet interface is really a strategy interface
for the type of step you're going to execute. In this case, you're configuring
org.springframework.batch.core.step.item.ChunkOrientedTasklet<I> . You don't have to worry about
configuring the class specifically here; just be aware that other types of tasklets can be used. The last
piece of the example step is the chunk tag. Here you're defining what a chunk is for your step. You're
saying to use the inputReader bean (an implementation of the ItemReader interface) as the reader and
the outputWriter bean (an implementation of the ItemWriter interface) as the writer, and that a chunk
consists of 50 items.
Note When you're configuring beans with Spring, it's better to use the id attribute than the name attribute. They
both have to be unique for Spring to work, but using the id attribute allows XML validators to enforce it.
It's important to note the commit-interval attribute. It's set at 50 in the example. This means no
records will be written until 50 records are read and processed. If an error occurs after processing 49
items, Spring Batch will roll back the current chunk (transaction) and mark the job as failed. If you were
to set the commit-interval value to 1, your job would read in a single item, process that item, and then
write that item. Essentially, you would be going back to item based processing. The issue with this is that
there is more than just that single item being persisted at the commit-interval. The state of the job is
being updated in the job repository as well. You experiment with the commit-interval later in this topic
but you needed to know now that it's important to set commit-interval as high as reasonably possible.
Understanding the Other Types of Tasklets
Although the majority of your steps will be chunk-based processing and therefore use
ChunkOrientedTasklet , that isn't the only option. Spring Batch provides three other implementations of
the Tasklet interface: CallableTaskletAdapter , MethodInvokingTaskletAdapter , and
SystemCommandTasklet . Let's look at CallableTaskletAdapter first.
org.springframework.batch.core.step.tasklet. CallableTaskletAdapter is an adapter that allows you to
configure an implementation of the java.util.concurrent.Callable<RepeatStatus> interface. If you're
unfamiliar with this newer interface, the Callable<V> interface is similar to the java.lang.Runnable
interface in that it's intended to be run in a new thread. However, unlike the Runnable interface, which
doesn't return a value and can't throw checked exceptions, the Callable interface can return a value (a
RepeatStatus , in this case) and can throw checked exceptions.
The adapter is actually extremely simple in its implementation. It calls the call() method on your
Callable object and returns the value that the call() method returns. That's it. Obviously you would use
this if you wanted to execute the logic of your step in another thread than the thread in which the step is
being executed. If you look at Listing 4-24, you can see that to use this adapter, you configure
CallableTaskletAdapter as a normal Spring bean and then reference it in the tasklet tag. In the