Transaction support with non-XA connection factory

[joerg-d-schneider-db]

Hi,

after several rounds of testing, it seems that the generic jms resource adapter mandates to have a XA connection factory in place, if we want to have transaction support (e.g. have the ability to rollback messages) since as soon as we have a transaction attribute set to support transactions, it tries to cast the underlying connection factory to a XA cf.

Most of our upstream systems where we consume messages from don't expose XA cfs - the only expose non-XA cfs. Nonetheless we naturally need to have the ability to rollback messages in case of any failure so we don't lose messages.

If we set transaction attribute "NOT_SUPPORTED" we don't get a class cast exception (see class JmsActivation line #440ff) using a non-XA cf, but it is impossible to rollback a message.

Any other transaction attribute supporting transactions (REQUIRED or REQUIRES_NEW ...) results in a class cast exception, as the underlying cf is a non-XA connection factory. Again, by no means we would be able to use a XA cf, as the cfs are setup by upstream systems beyond our control.

Simple question : how can that adapter be used with a non-XA cf but still having the ability to rollback messages ? We do exactly that with a IBM WSMQ resource adapter without any problems.

I'm also unclear why there is a strict cast to XAConnectionFactory, even if the underlying "preliminaryObject" can be checked if it is an instance of XACF or not - why not simply check if the cf is XA or non-XA and then do the proper cast ?

Any help appreciated - thx.