3 Replies Latest reply on Nov 28, 2001 6:52 PM by davidjencks

    transaction mode specified in JCA deployment descriptor

    mark_dixon

      Hi,
      When I develop a resource adapter, how do I now what
      is the 'transaction-support' specified? The samples
      and the reference implementation use different MCF
      interfaces for different transaction types. But, if
      I have the same MCF interface for all transaction
      types, then how will my connection factory know the
      transaction mode.
      I am wondering why did the JCA implementors choose
      to define different interfaces for the transaction
      types ? Isnt it more user-friendly to define one
      MCF interface and then use the deploy tool to specify
      the transaction-support, maybe via property-set ?

      -Mark

        • 1. Re: transaction mode specified in JCA deployment descriptor
          davidjencks

          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.

          • 2. Re: transaction mode specified in JCA deployment descriptor
            mark_dixon

            > 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.
            Hi David,
            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.

            -Mark

            • 3. Re: transaction mode specified in JCA deployment descriptor
              davidjencks

              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.