9 Replies Latest reply on Sep 24, 2006 4:18 PM by weston.price

    XAResourceWrapper for WebSphereMQ XA (JBAS-3183)

    weston.price

      The WebSphereMQ XA bug requires that the underlying XAResource from WASMQ be wrapped to return false to the isSameRM method. This is the same situation that required the Oracle override flag in XAManagedConnectionFactory.

      My plan is to add a flag to the JmsManagedConnectionFactory that would enable wrapping the XAResource if this is required.

        • 1. Re: XAResourceWrapper for WebSphereMQ XA (JBAS-3183)

          This should be done generically in the TxConnectionManager
          for the other reasons we talked about.

          e.g.
          1) moving the pad=true out of the transaction manager to be resource specific
          2) Passing vendor specific flags to the XAResource

          • 2. Re: XAResourceWrapper for WebSphereMQ XA (JBAS-3183)
            weston.price

            Got it...will do....

            • 3. Re: XAResourceWrapper for WebSphereMQ XA (JBAS-3183)
              weston.price

              Actually, if we could talk about this a bit more that would be great :-)

              I am not quite sure how we can make the pad flag resource specific since we aren't generating the Xid.


              Sorry for my stupidity but I just don't quite remember all of the details we discussed.

              • 4. Re: XAResourceWrapper for WebSphereMQ XA (JBAS-3183)
                bill.burke

                Couldn't you just intercept any XID interaction between the adapter and TM and just morph it to what it should be?

                • 5. Re: XAResourceWrapper for WebSphereMQ XA (JBAS-3183)
                  weston.price

                  The Xid is immutable and doesn't allow direct modification. Further, situations where we don't provide the XAResource (JMS); without a wrapper of some sort gets problematic.

                  This is the real issue with the WASMQ XA mess.

                  • 6. Re: XAResourceWrapper for WebSphereMQ XA (JBAS-3183)

                    We already do something similar in JBossMQ to make sure the Xid is serializable.

                    See org.jboss.mq.JBossMQXid

                    It should just be a case that when pad is true we create a new
                    xid from the old one.

                    P.S. Since Oracle fixed the problem in their latest releases
                    this feature is only useful anyway for legacy Oracle.

                    • 7. Re: XAResourceWrapper for WebSphereMQ XA (JBAS-3183)

                       

                      "weston.price@jboss.com" wrote:
                      The Xid is immutable and doesn't allow direct modification. Further, situations where we don't provide the XAResource (JMS); without a wrapper of some sort gets problematic.

                      This is the real issue with the WASMQ XA mess.


                      All XAResource usage should be moving into to the JCA layer,
                      including inbound JMS.

                      • 8. Re: XAResourceWrapper for WebSphereMQ XA (JBAS-3183)
                        weston.price

                         


                        P.S. Since Oracle fixed the problem in their latest releases
                        this feature is only useful anyway for legacy Oracle.


                        Well, if you assume everything prior to release 10.2 to be 'legacy' then yeah, ok :-)



                        • 9. Re: XAResourceWrapper for WebSphereMQ XA (JBAS-3183)
                          weston.price

                          Work on this continues. To this point what has been done is:

                          A new package with the JcaXid and the new XAResourceWrapper has been created and is in HEAD.

                          The TxConnectionManager has been updated with properties PadXid, UseXAResourceWrapper and isSameRMOverride. If the UseXAResourceWrapper is set to true an XAResourceWrapper is generated on TxConnectionManager.createConnectionListener.

                          The primary purpose of the XAResourceWrapper it to provide the isSameRMOverride capablity, as well as the padding of the Xid if requested via the JcaXid.

                          Most of this was adopted from stuff that exists (XAResourceWrapper in jms recovery and JBossMQXid).

                          Remaining work is to get the PadXid stuff out XidFactory and get rid of the isSameRM in the existing XAManagedConnectionFactory.

                          In looking at the JBossTS doc, the recovery stuff should be take care by the XAResourceWrapper being serializable. More to the point:


                          If the XAResource is serializable, then the serialized form will be saved during transaction commitment, and used during recovery. It is assumed that the recreated XAResource is valid and can be used to drive recovery on the associated database.


                          No failures in the testsuite regression have shown up. Just making sure I am covering all the bases.