[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB

[weston.price@jboss.com]

anonymous wrote : 
  | Well, yes I agree this may be unusual, although I don't believe it it illegal. 
  | 

No, not illegal but it certainly makes deploying non XA JMS based resources with JBM all but impossible while using the JMS/JCA adapter. While this is not necessarily a bad thing, it simply says that when using JCA/JMS in conjunction with JBM you currently have no choice but to use XA which in most scenarios is exactly what you want.

anonymous wrote : 
  | It seems to me the JCA is making an incorrect assumption that a particular connection instance can't be both a Connection and an XAConnection. It just so happens up to now JBM is the only provider that implements it this way. 
  | 

The JMS/JCA adapter does not make any assumptions beyond that which is specified in the requisite configuration files (ie *-ds.xml for outbound connectivity and the  activation-configuration for inbound). 

The JCA/JMS adapter is designed for generic JMS integration with any JMS provider, not just those implementing the optional XA API.
What is bound into JNDI and relayed to the adapter via the JMSProviderAdapter is what determines it's use in the context of a global transaction. 

If an XAConnectionFactory (or it's XA specific counterparts per domain) is bound into JNDI and registered with the adapter via the JMSProviderAdapter configuration property, the adapter uses this. If not, the traditional JMS API is used. 

This is *by design*. Being that XA is optional for an JMS provider this is used to support providers that do not implement XA but still may want to participate in a global transaction via the LRCG (Last resource commit gambit) much in the same manner as the local-tx-datasource. Similarly, it is used to support clients that do not want to use XA at all and be transaction ignorant (no-tx-connection-factory) and perhaps utilize the local JMS transaction API to control the transaction themselves (Session.commit(), Session.rollback()) while still getting the benefit of connection pooling.

In other words, if you want XA you deploy the correct JMS adminstrative objects to support this. If not, or you can't because your JMS provider doesn't support it, you don't. To reflect this you configure your *-ds.xml file (and JMSProviderAdapter) appropriately. 

Having said all of this, I am not sure that any of this is the cause of the failures in the testsuite/TCK. Without specific stack traces/errors I can't determine what the issue is or if it pertains to JCA/JMS at all. The test offered an example is a perfectly supported use case under JBossMQ, but that isn't saying all that much. Without more information, I simply can't tell. I am more than happy to look at the issues if you want just point me to a specific trace/error that I can review. 












View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040064#4040064

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4040064