Transactions?

[magnusheino]

Is there anything to say about using Spring Integration with JMS, databases, and transactions?

In current applications, you might starta a transaction, read a jms message, do some work, update the db, and then commit both the jms read and db write. How are things like this done using Spring Integration? When are jms things acknowledged, or committed? What if I spawn things with concurrent endpoints etc?

[Mark Fisher]

Magnus,

One of the main items on the list for 1.0-M2 is to provide a foundation for transaction support in Spring Integration. Initially this will consist of configurable transaction policies for endpoints so that MessageHandlers that are invoked during an endpoint's processing of a received Message will be able to participate in the same transaction context. These transactions may then propagate to service objects that are invoked by the handler(s).

As far as the JMS + DB transaction that you are describing, the scenario is different within Spring Integration due to the inherently asynchronous model. Once a Message is passed to a channel, the sending thread is no longer responsible. Rather, the receiving thread will handle the Message and will in fact typically delegate the handling task to a thread from the endpoint's pool. Currently, the JmsMessageDrivenSourceAdapter creates a DefaultMessageListenerContainer and sets 'sessionTransacted' to true, but as long as the MessageListener (ChannelPublishingJmsListener in this case), is able to send the Message to the adapter's channel without a failure or timeout, then the JMS transaction will be successful. If that same Spring Integration Message is later processed by a MessageHandler that invokes a service and performs DB updates, that will occur in a different transaction.

There are a number of things being considered for extending the basic transaction support. For example, configuring a 0-capacity channel will enable a "direct-handoff" so that the Message sender's transaction may either fail or timeout unless the Message arrives at an actual endpoint (rather than just arriving at the channel). Also, by using a Transactional Client, the asynchronous invocations will appear synchronous from the caller's perspective (similar to a JMS QueueRequestor), and thus the client could rollback based on an error reply or timeout. These are in the works for M2. Please keep an eye on the progress, and continue to offer feedback!

Thanks,
Mark