timfox wrote : | Because an XASession is supposed to be transactional and it's transactonal state transitions are supposed to be determined by the transaction manager invoking methods on it's XAResource. | XASession is supposed to be transactional only if its XAResource is enrolled in a transaction. This is not the case for the situation we discuss. There's no active JTA transaction at the time of session creation. The transaction manager cannot modify the state of the session, since there's no association with any transaction. Hence, the specific session we talk about is non-transactional (even if the object instance associated with the session implements XASession. It's the same way as saying that an object that implements Runnable must have its run() method executed by a thread at all times). timfox wrote : | JBoss MQ is adding an extra semantic by saying, as well as the above, if the XASession is not enlisted in any transaction it should act non transactionally. | In my opinion JBossMQ is just adding common sense. timfox wrote : | As an analogy, if you obtained an XA database connection from Oracle but forgot to enlist it in a transaction, then did some database operations, you would be suprised if you discovered it had gone into auto commit mode. | I wouldn't be surprised, actually. Can you tell exactly what's the behavior of a XA database connection in this circumstances? timfox wrote : | But that is exactly what you are expecting a jms xa connection to do. | Yes, this is what I expect. None of us was able to produce spec paragraphs confirming or proving invalid our assumptions. How about trying the reference implementation? That would be the next logical step. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968753#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...