How to set Transaction timeout on SubscribableJmsChannel

[atexan]

When I use PollableJmsChannel, we were able to set transaction timeout/isolation/propagation using poller's transaction element. (JMS channel with messagedriven=false)

We are using a SubscribableJmsChannel (JMS channel with messagedriven=true) (for which I have configured transaction manager and also configured a task executor) I haven't seen a way to set transactional context at all (such as time out/isolation/propagation). We can only set receive time out on this type of channel.

SubscribableJmsChannel does use transaction manager to retrieve message from the queue; however, I am not sure whether the same transaction is going to be propagated to the handlers on the channel.

How are the transactions managed in this case?
What is the transactional context under which all the down stream handler are going run?
Will the send operation on the JMS queue participate in the same transaction as the downstream handlers?

Thanks

[Mark Fisher]

In the message-driven case, transactions can be managed directly at the JMS Session level without a need for the TransactionManager. Since the underlying container is actually *starting* the transactions, there may not be any real value in controlling something like propagation. Also, from a pure JMS transaction perspective, isolation level is not applicable either. Can you explain your use-case and why those configuration properties apply to the bigger picture?

Thanks,
Mark

[atexan]

When there is an exception in the handler; transaction should be rolled back and the message should not be consumed out of JMS queue. We should be ablet to set different timeouts for these trasactions as some of the downstream handlers may end up executing long running transactions.

If there is no transaction timeout setting per this thread, then I have to increase the transaction timeout for the entire server, which is not desirable.

I didn't understand what you mean by "the underlying contrainer is initiating the transaction". I looked at the code for SubscribabaleJMSChannel; it is using DefaultMessageListenerContainer (subclass of AbstractPollingMessageListenerContainer) that is polling the JMS queue (and dynamically scaling the consumers). Shouldn't it be the one initiating the transaction and JMS server is just another resource participating in the transation?

In both Pollable and Subscribable JMS channel case, Spring integration is doing the polling. One would except that Subscribable JMS channel be notified by the JMS server (just as MDB); I guess it is not possible without hooking into the underlying JMS server infrastrure.

I see the adavantages of dynamic scaling feature of Subscribable JMS channel which is better than Pollable one in terms of not wasting resources. However, I believe, Pollable JMS implementation is providing far greater transaction handling benefit.

Thanks

[Mark Fisher]

Sorry, I must not have been very clear. What I meant by the "underlying container" *is* the DefaultMessageListenerContainer, and it does provide the "message-driven" functionality. It initiates the transaction, and when no "transaction-manager" is provided, those will be JMS Session-level transactions. I understand your need for a transaction timeout setting due to the downstream handlers. That can be accomplished by setting the "defaultTimeout" property on a JmsTransactionManager instance that you then provide via the "transaction-manager" reference attribute on the 'channel' element. The underlying DefaultMessageListenerContainer does also provide a setTransactionTimeout() method, but we are not currently exposing any attributes that would handle that when using the namespace support.

Does that clarify things a bit?
-Mark

[atexan]

That helps; thats a perfect explanation.

Is it possible to get different transaction manger instances to set different timeouts just as a work around?

I believe for any framework to be considered robust and enterprise worthy, they need to have good transaction and clustering support.

Are you planning on fixing this in the next release?

[Mark Fisher]

Of course you can define different JmsTransactionManager instances if you need multiple timeout values.

What exactly is it that you would like to have "fixed"? I honestly don't understand the implication that we do not have robust transaction support. We're just using the core Spring transactions which is definitely a robust solution.

[atexan]

We are using JTA transaction manager. And setting the default timeout worked well.

---- "The underlying DefaultMessageListenerContainer does also provide a setTransactionTimeout() method, but we are not currently exposing any attributes that would handle that when using the namespace support."

Can we expose setTransactionTimeout() on DefaultMessageListenerContainer through JMS channel config or trasactional element?

I didn't mean to say that neither Spring not spring integration don't have transaction support. I am just eluding to the point that spring integration is missing a few facilities such as above (and specifically clustering support for scalability) to make it a pefect integration solution.

Since I started using Spring Integration, I started loving it and the way it was written is much more elegant. Thank you all for working so hard and making it easy for us.

[Mark Fisher]

Can we expose setTransactionTimeout() on DefaultMessageListenerContainer through JMS channel config or trasactional element?

As far as I understand, that is the *only* thing which you think should be "fixed"? Please let me know, otherwise.

There is a reason that we were hesitant to expose that attribute via the namespace support. So, let me explain.... Since the 'channel' element is used for both polling and message-driven, the "transaction-timeout" as an attribute on the top-level element would only apply to the message-driven case (whereas with a polling channel, it is already configurable on the transactional sub-element of the poller element). That means we would need to verify that the attribute is not provided when message-driven="false". Obviously that can be a source of confusion, so we left it out initially. If you would like to raise a JIRA issue requesting to have it added anyways, feel free.

Also, please keep in mind that the namespace support is only a convenience. You can easily define a <bean> for the JMS channel instance and configure its DefaultMessageListenerContainer however you would like. It is very common in Spring generally that the namespace exposes the most common attributes, but not every single configuration option.

Finally, can you describe in more detail what you have in mind when you say "clustering support"? Spring Integration is quite usable in a clustered environment considering it's mostly stateless, and the stateful components (e.g. aggregator) can delegate to strategies that are shared across a cluster (e.g. JdbcMessageStore). I would like to know what you see as missing.

Thanks!
-Mark