Desired step flow:
[![Desired step flow](https://i.stack.imgur.com/OgacC.jpg)](https://i.stack.imgur.com/OgacC.jpg)

The expectation is that in the scope of a single XA transaction, the step will:

1. Select the partitioned data
2. Write the **unaltered** partitioned data to an audit table (redo log) using the JDBC BatchUpdate
3. invoke the ItemProcessor on the **unaltered** data
4. use a composite writer to batch write additonal operations to additional targets

The puzzle I am trying to solve is that the process needs to read the partition once only, and operate strictly within the bounds of that selection.

If there is no "wiretap" configuration to accomplish this, a solution I am considering is to implement the batch write to the redo log in the reader itself, but that just feels ugly, like it defeats the purpose of the framework. If there is already a spring batch pattern for this it would be much better.

We are using the spring batch XML definitions because it gives a degree of control over bean scoping that the DSL does not permit.

Since spring integration is already a part of this project for other functions, another option might be to refactor this as a spring integration flow.

---

**(Edit 3: Notes about answers)**

Both Artem and Mahmoud's answers are correct. I have fleshed out designs for both scenarios, far beyond what is shown on this question. I wish I could flag them both as correct, so make sure to upvote Artem's answer and give him due credit.

The advantage to Artem's answer is that, with a little refactoring of existing code I could eliminate the spring batch from the worker side of the architecture, and reduce our code to simplify some other operations that are not referenced in this question. The disadvantage is it would require a much more major refactoring and addressing a learning curve that is simply huge.

The biggest advantage to Mahmoud's answer is specific to my case: I can implement it with code paradigms that are already familiar to my team and are already core to the existing product.

Both should be nearly equally efficient. I would actually have to implement both to measure efficiency.

In the context of my project, I have elected to follow Mahmoud's answer because it requires the least changes to the current design and code paradigm.

---

**(Edit: alternative flow build in Spring Integration)**

Based on comments from @Artem Bilan, I have started a design to refactor to Spring Integration.
Not visible:

* flows and flow elements are created dynamically at runtime by a rules engine, and destroyed when no longer in use
* each flow encompasses a chain of readers that may or may not be JDBC

[![alternative flow build in Spring Integration](https://i.stack.imgur.com/ZTfh0.jpg)](https://i.stack.imgur.com/ZTfh0.jpg)

**(Edit 2: Refinement of spring batch architecture)**

Based on comments from Mahmoud Ben Hassine, there are Listener hooks we can leverage. The refined graphic shows the ItemProcessListener being used for both audit requirements, although this is not necessarily the final code we will use.

[![Refined steps Spring Batch](https://i.stack.imgur.com/O5cse.jpg)](https://i.stack.imgur.com/O5cse.jpg)

Any thoughts or advice is welcome.