<beans:property name="jobExplorer" ref="jobExplorer"/>
<beans:property name="stepLocator" ref="stepLocator"/>
<int:aggregator ref="partitionHandler" input-channel="inbound-staging"
The configuration for the job begins with the job itself. Although the name and the step's name are
the same here as they were in the remote-chunking example, what this step does is quite different.
Step1.master serves as the master step, which doles out work to the slaves and aggregates the resulting
statuses to determine whether the step was successful. The partition step for step1.master requires two
dependencies: an implementation of the Partitioner interface to divide the work into partitions and a
PartitionHandler to do the work of sending out the messages to the slaves and receiving the results.
ColumnRangePartitioner is the implementation of the Partitioner interface that you're using for this
example. As you saw in Listing 11-29, ColumnRangePartitioner extends Spring's JdbcTemplate , so it
depends on a DataSource implementation as well as the required table and column to use for
partitioning and the number of slaves ( gridSize ) so you can divide the work appropriately.
The step that is configured after the partitioner is the exact same step used in the remote-chunking
example. But this step is run as your slave worker as opposed to within the context of a job. Along with
the configuration of the step, you configure its ItemReader and required RowMapper implementation
( customerReader and customerRowMapper ), an ItemProcessor ( geocoder ), and an ItemWriter
( customerImportWriter ).
Next, you move on to the configuration of the beans related to partitioning. Because the
PartitionHandler is the center of the processing for a partitioned step, let's begin with it.
org.springframework.batch.integration.partition.MessageChannelPartitionHandler requires four