Spring Integration : Read from JMS -> Handle message -> Persist in DB - spring

Question

I use Spring Integration to read messages from JMS, handle them and then persist them to the database using my own dbPersistor's persist method which has a return type void. I wrote a test case to verify the messages published to the JMS were successfully persisted in the db. My SI and JMS configuration are as follows for this test -
<int:poller fixed-delay="500" default="true"/>
<int:channel id="inputChannel">
<int:queue/>
</int:channel>
<int:channel id="errorChannel">
<int:queue/>
</int:channel>
<jms:message-driven-channel-adapter id="jmsInboudAdapter"
connection-factory="connectionFactory" destination-name="MessageQueue"
channel="inputChannel" error-channel="errorChannel" transaction-manager="dbTxManager"
acknowledge="transacted"/>
<int:chain id="handlerChain" input-channel="inputChannel">
<int:service-activator ref="jmsMessageHandler" method="handleMessage" />
<int:service-activator ref="dbPersistor" method="persist" />
</int:chain>
Then in the test I do the following -
jmsTemplate.send()
verifyMessageWasPersistedToDB
This works great when I just publish a single message to the db. But when I loop through jmsTemplate.send() to publish multiple messages, the main thread completes the operation while the SI threads are still executing and tries to verify the messages in DB and fails as some of the messages have not been persisted yet. My questions are -
How do I make the main thread to wait for the SI threads to finish and then invoke the verify method?
In case of a db exception and rollback how do I verify that the failed message is back in the original queue?
Thanks
AJ

Answer 1

inputChannel should not be a queue channel - the JMS transaction will commit when the message is inserted in the queue - the DB transaction won't be performed in the scope of the JMS transaction. You must use direct channels for that (remove the poller and <queue/>). See the documentation on transactions in Spring Integration.
You will have to poll the database for results; you could probably add an interceptor and some CountDownLatch but it's easier to just poll the DB until the results appear or some time expires.