Announcement Announcement Module
Collapse
No announcement yet.
MessageListenerContainer, sessionTransacted and JmsTransactionManager Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • MessageListenerContainer, sessionTransacted and JmsTransactionManager

    Hello,

    For Spring 2.5.4:

    When using the DefaultMessageListenerContainer with sessionTransacted set to true, we observe that the JMS session is committed before the JMS MessageConsumer is closed.

    The call to commitIfNecessary() on line 449 of AbstractMessageListenerContainer successfully commits because the transaction is "local". This happens before the session.close() call.

    Conversely, when using the DefaultMessageListenerContainer with sessionTransacted set to false, and a JmsTransactionManager as the transactionManager property ref, we observe that the JMS session is committed after the JMS MessageConsumer is closed.

    The call to commitIfNecessary() on line 449 of AbstractMessageListenerContainer does nothing (it neither rolls back nor commits) because the transaction is "not local"; instead, the transactionManager.commit() call on line 254 of AbstractPollingMessageListenerContainer causes the commit() call on the session. This happens after the JMS MessageConsumer is closed.

    The JMS spec isn't particularly clear about what constitutes "valid" behavior, but this causes bizarre issues with one of our JMS providers (SonicMQ).

    We had understood that setting sessionTransacted to true would yield the same results as providing a JmsTransactionManager (we chop and change between JmsTransactionManager and JtaTransactionManager is different environments/codebases and would prefer to have the flexibility of enlisting in JTA tx's downstream if necessary).

    Does this strike anyone as being odd? Is our assumption correct?

    Thanks
    JC
Working...
X