I don't really understand much of what you said.
If you write a resource adapter, that supports any kind of transactions, you must implement spi.LocalTransaction or XAResource. You give a hint in ra.xml how much support there is. The rar deployer could look at that info and guess how the ConnectionManager (part of the app server) should try to control transactions with the resource adapter: however in jboss at the moment you have to specify what sort of transactions you want to control, by specifying No Transactions, LocalTransactions, or XATransactions with your choice of ConnectionManagerFactoryLoader in the ConnectionFactoryLoader mbean configuration.
Different resource managers have different levels of transaction support. Its pretty useless to ask someone implementing a connector for a non-transactional resource manager to supply an XAResource: it couldn't do anything except sit there throwing exceptions whenever you called one of its methods. You could use XAResource to manage LocalTransactions, but I think would be highly confusing and misleading, tempting the unsuspecting user who doesn't really understand what 2pc is or is for to try to use such a resource adapter in 2pc transactions, thus preventing anything from committing. Of course, you could argue that is better than the current state of not telling users that they don't really have transactional behavior if one of the resource adapters only supports LocalTransaction.
> Different resource managers have different levels of
> transaction support. Its pretty useless to ask
> someone implementing a connector for a
> non-transactional resource manager to supply an
> XAResource: it couldn't do anything except sit there
> throwing exceptions whenever you called one of its
I apologize for confusing you with my questions.
My main concern is that for a resource that
supports all three transaction modes, why does it
need 3 MCF interfaces ? If the MCF knew the
transaction-support it can instantiate the
appropriate MC instances.
For a non-transactional resource manager, it will
always create non-transaction MCs. It need not
implement XAResource and LocalTxn interfaces.
If a resource adapter supports xa, it can also optionally supply a spi.LocalTransaction implementation, and the ConnectionManager/app server can presumably (hopefully?) be configured to use one or the other. The latest version of the spec also explains about autocommit behavior, at least for cci Connections (anything outside an explicit transaction should be autocommitted). So one mcf implementation can support all 3 levels of transaction support. This is more or less what I did with the firebird jca-jdbc driver last weekend. (It has always supported LocalTransaction [although only exposed as cci.LocalTransaction at the moment] and I added autocommit behavior).
I'm not sure why you would use spi.LocalTransaction on an mcf that provided an XAResource implementation -- maybe its just my implementation, I don't see why it would give you any advantages.