4 Replies Latest reply on Mar 7, 2005 11:43 AM by Steve Lewis

    Moving Xids from XidFactory to XAManagedConnectionFactory

    Steve Lewis Expert

      The issue, that http://jira.jboss.com/jira/browse/JBAS-1405:

      So we can take out the Xid padding from the XidFactory, and pad the Xid right before sending it to start and end. But according to Bill Burke in that issue,

      "The way this will work will be to add the padding flag to both the ManagedConnectionFactory wrapper and to the Connection Manager."

      And then ...

      "One more comment, ConnectionManager will use this metadata and store it within a ConnectionListener. The ConnectionListener will be responsible for doing padding on the XAResource if it requires it."

      So I understand how to make the metadata, and set it using it an -xa-ds.xml file, which would set a flag in the TxConnectionManager instance. The TxConnectionManager would then be passed into the XAManagedConnectionFactory.

      My question is: Will the ConnectionListener really be the one to pad? The XAManagedConnection is the one with the

      start(Xid xid, int flags)
      end(Xid xid, int flags)

      methods. Couldn't the flag get passed on to the XAManagedConnection and allow the XAManagedConnection to be responsible? Maybe there's something I'm missing but the ConnectionListener doesn't seem to do much. Or maybe it needs to use the Xid for recovery.

      Thanks,

        • 1. Re: Moving Xids from XidFactory to XAManagedConnectionFactor
          Adrian Brock Master

          First, you shouldn't *remove* the XID padding from the XIDFactory.
          There are lots of people using that configuration.
          Instead, it should be deprecated in favour of the new configuration.

          • 2. Re: Moving Xids from XidFactory to XAManagedConnectionFactor
            Adrian Brock Master

            On the main point, we don't control/write the ManagedConnectionFactory or ManagedConnection. These are application classes.

            But we do control where these are created and we can wrap them with our
            own processing, e.g. ConnectionListener wraps ManagedConnection.

            What we actually want to wrap is the XAResource associated with the ManagedConnection
            to perform any necessary padding or flag manipulation.

            In particular we want to modify the start()/end() used by our ConnectionListener
            and recover() used by the yet to written Recoverable implementation.

            This processing then becomes transparent to the transaction manager
            and is configured/controlled at each resource.

            • 3. Re: Moving Xids from XidFactory to XAManagedConnectionFactor
              Adrian Brock Master

              There are some other places that "play" with XAResources
              like the inbound message processing (MessageEndpoint)
              and the old JMS mdb processing (org.jboss.jms.asf)

              • 4. Re: Moving Xids from XidFactory to XAManagedConnectionFactor
                Steve Lewis Expert

                Oh. Duh. Yes, of course. An XA resource adapter won't use XAManagedConnectionFactory or XAManagedConnection. They'll have their own implementations. So doing it on the ConnectionListener makes total sense.

                Thanks.

                "adrian@jboss.org" wrote:
                On the main point, we don't control/write the ManagedConnectionFactory or ManagedConnection. These are application classes.

                But we do control where these are created and we can wrap them with our
                own processing, e.g. ConnectionListener wraps ManagedConnection.

                What we actually want to wrap is the XAResource associated with the ManagedConnection
                to perform any necessary padding or flag manipulation.

                In particular we want to modify the start()/end() used by our ConnectionListener
                and recover() used by the yet to written Recoverable implementation.

                This processing then becomes transparent to the transaction manager
                and is configured/controlled at each resource.