You can sort of hack it using a <split/> to run 2 steps at once. Step 1 would write to a queue which Step 2 can read from. The key here will be to make sure your Step 2's reader has a decent timeout on the MessageConsumer so it can wait long enough for Step 1 to write a chunk to the queue.
<split id="splitStep" task-executor="asyncTaskExecutor" >
<flow>
Step 1: reader -> processor -> writer (to queue)
</flow>
<flow>
Step 2: reader (from queue) -> processor -> final writer
</flow>
</split>
That said, is there a reason why you can't just use a composite processor?
Step 1: reader -> processor 1 -> processor 2 -> writer
Or better yet, do you need to chunk this? It might be a better use case for Spring Integration or something.
And if you truly do need chunking, you could instead hack your reader to return a List and then use composite processors to chain your transformations of the entire chunk.
Reader: reads source, returns List<SourceItem>
Processor 1: List<SourceItem> in, perform transformations, List<TransformedItem> out
Processor 2: List<TransformedItem> in, additional transformations, List<FinalItem> out
Writer: List<List<FinalItem>> in, unpack the list, write to final destination
If you were to do this, you'd be circumventing how the framework typically works, so you'd need to set your commit-interval to 1 (because you only want the reader to return 1 list) and instead determine chunk size in your reader by changing the # of items in that list.