1
votes

I have a Spring Integration jdbc:inbound-channel-adapter which reads from a database. An important requirement is that the same rows are not read twice. One possible approach may be to use the update attribute to set a flag on the rows read using the same where clause as for the query attribute. The concern however would be that if an exception occurs further on in the workflow (transforming the result set using the row mapper, marshalling to XML, and then placing on an outbound queue for an external system), those rows would not be re-read when the application came back up. Is there a better strategy to use in this case with Spring Integration?

Another question would be that, given the above requirement, would Spring Batch offer a more robust solution, and if so, how would this be implemented? Thanks

1
Can you explain why don't use transactions for your case? If there will be something wrong, any changes in DB will be rollbackedArtem Bilan
those rows would not be re-read when the application came back up What that's mean?Ruslan

1 Answers

0
votes

Looks like you should use the short TX and channel shift technique:

<int-jdbc:inbound-channel-adapter channel="executorChannel"/>

<int:channel id="executorChannel">
    <int:dispatcher task-executor="executor"/>
</int:channel>

Having that your message will be shifted to the different Thread outside of JDBC TX. And the last one will be commited always. So, any downstrem issues won't affect you row in DB - they will be marked as processed and won't be read one more time.