Announcement Announcement Module
No announcement yet.
Session transacted not getting set as expected with DefaultMessageListenerContainer Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Session transacted not getting set as expected with DefaultMessageListenerContainer

    I've been working more and more with the DefaultMessageListenerContainer and am seeing unexpected results when setting a JmsTransactionManager on the container.

    I would expect, and the documentation seems to back this up, that setting a transaction manager would force the session to be transacted. And looking at the following piece of code in AbstractPollingMessageListenerContainer seems to generally back that up:

    	public void initialize() {
    		// Set sessionTransacted=true in case of a non-JTA transaction manager.
    		if (!this.sessionTransactedCalled && this.transactionManager instanceof ResourceTransactionManager &&
    				((ResourceTransactionManager) this.transactionManager).getResourceFactory() != getConnectionFactory()) {
    		// Use bean name as default transaction name.
    		if (this.transactionDefinition.getName() == null) {
    		// Proceed with superclass initialization.
    However, it's the != on this condition that is confusing me:
    ((ResourceTransactionManager) this.transactionManager).getResourceFactory() != getConnectionFactory()
    So what is happening to me, when wiring my beans together, if the container and the tx manager share the same singleton jms connection factory, my session will not be transacted. I would expect the opposite. That if the resouce pointed to by the container and the tx manager DO equal, that's definitely the piece you want transacted.

    So my question is, is there something I'm missing here or should that be changed to ==? Or is that condition even necessary at all and can just be removed?

    Right now I work around by simply setting sessionTransacted myself, creating the jms connection factory with a scope of prototype (or I can even point the tx manager to an entirely different jms provider and that works).

    Thanks for any help you can give me.