Spring DMLC + Message Batch + DB update

I have a stand alone DMLC consumer listening to an activemq JMS broker, and badly need your help to achieve the following in Spring DMLC consumer. here's what I am trying to achieve

1. Need to facilitate the local transaction to group/batch the messages which are getting received i.e similar to MessageConsumer.receive(MILLISECOND) , so all messages getting received in the specified time out or a specified max count should be able to transacted together, hence will be acknowledged once all messages in the group has become successful.

2. From the same consumer, I need to push all these messages to DB, so primarily to avoid flooding the DB server with so many Inserts, I might need to insert/update those messages as batchinsert or update.

3. So primarily need a mechanism to specify the programmatic transaction boundaries and etc.

I think by default DMLC invokes MessageConsumer.receive() method in a loop, so that the messages will get consumed as it arrives. As I know that it's possible to group the messages as it arrives using local transaction and etc, need your help to understand the configuration in spring.

Any sort of help will be deeply appreciated, and I am trying different combinations too.

Also will some one explain me what will happen for the messages when I say acknowledge="transacted" or sessionTransacted="true" for the DMLC. Will it still wrap its receive() method in a single transaction ? what will happen if I am adding a DB update statement in the onMessage() method, will that be in the scope of this transaction ? I assume DB statement will not be part of that transaction, instead we need to use JTA or DataSource Transaction managers externally. Please share your understanding on these points as well.

The JMS and DB operations will not be in the *same* transaction but the DB's transaction scope is essentially nested within the JMS transaction scope. This means if the DB op rolls back and propagates an exception, that exception will also trigger a rollback for the JMS transaction. The "window of vulnerability" that does exist however is if the JMS commit fails for some reason and yet the DB commit has already passed. That can be handled, however, with a strategy for handling dups (idempotent receiver).

This article provides much more detail and should help you understand the big picture and tradeoffs between various approaches:
http://www.javaworld.com/javaworld/j...nsactions.html

Hope that helps.
-Mark

Thanks Mark for the quick reply. Right now I am looking through the documentation that you have mentioned, mean time it will be really great if you could show some light on my first concern, i.e. Message batching ?

I have the same question as Vijesh regarding batching. We have just finished investigating a different EIP framework that was otherwise very promising, but we couldn't figure out how to handle multiple JMS messages and database updates in one XA transaction. The performance was abysmal, processing one message at a time.

Right now we're looking at using Spring Batch, which gets us the performance we need. But the system we're building is message-driven, so it's a bit of a kludge.

Does anyone know whether Spring Integration is able to process JMS messages in batches? I haven't been able to find any documentation saying one way or the other.

Regards,
Sam Bishop