3 Replies Latest reply on Aug 17, 2002 11:38 PM by Brian Macy

    Strange JBoss/JCA XAResource usage (3.0.1rc1)

    Brian Macy Newbie

      I've been cleaning up the pseudo-XA PostgreSQL driver a little so I can sanely use it with JBoss and noticed an interesting issue with the ordering of calls on XAResource that is definitely not spec complaint.

      XAResource A: start(xid1, TMNOFLAGS);
      XAResource A: start(xid2, TMJOIN);

      This is definitely not allowed and I'm curious if anyone has noticed this. The version of code that I started with didn't check this condition.

      Brian Macy

        • 1. Re: Strange JBoss/JCA XAResource usage (3.0.1rc1)
          David Jencks Master

          I'm curious as to why you would spend your time trying to make a psuedo xa driver work when it won't provide you different semantics than the jdbc 1 driver. Am I missing something?

          Can you provide more info on how you got this sequence of calls to occur? Is Postgres handing out the same XAResource from more than one connection?

          I assume you are using the Minerva xa wrapper. I'd appreciate it if you would try the new wrapper I committed to jboss 4 (cvs head) yesterday. So far it is untested, but if it is a problem with the wrapper I would rather fix the new version.

          • 2. Re: Strange JBoss/JCA XAResource usage (3.0.1rc1)
            Brian Macy Newbie

            There are actually several reason for using it:
            - To get rid of the warning whenever I use JMS and CMPs in the same transaction (though I'm betting there are ways to disable it)
            - 2pc is on the list of post Pg 7.3 items to address and I'd like to be familiar with the obsoleted Pg JDBC XA code and JDBC XA in general when it comes time that Pg can actually support it (this is *not* Minerva, but code in the Pg JDBC tree)
            - Minerva source is difficult to find... in fact the only location I found it was in the Attic of the JBoss tree.
            - When I looked at the Minerva commit function scared me... why is the onePhase variable named twoPhase???
            - Minerva requires that commit be called *before* another transaction starts... this can be supported in JDBC 1.0.
            - I have yet to find a working Minerva wrapper configuration or documentation for JBoss 3.0.x

            If you have a jar file for the JBoss 4 XA wrapper class that I can deploy into JBoss 3.0.x I would be happy to try it.

            As far as getting a repeatable case of the strange start behavior, I'll have to get back to you on that as I'll need to come up with a small test case but I don't believe I'm doing anything unusual... just JMS, MessageDrivenBean, and EJB.

            It is also weird the way JCA uses JOIN semantics though I don't think it is technically a spec violation...

            XAResource A: Xid 1 JOIN
            XAResource A: Xid 1 SUSPEND
            XAResource A: Xid 2 JOIN
            XAResource A: Xid 2 SUSPEND
            XAResource A: Xid 1 JOIN
            XAResource A: Xid 1 TMSUCCESS

            Since XAResource A has "seen" Xid 1, I would expect the second JOIN to be a RESUME. But again, I don't think the JTA spec is clear on the definition of "seen" so this is likely perfectly valid.

            Brian Macy

            • 3. Re: Strange JBoss/JCA XAResource usage (3.0.1rc1)
              Brian Macy Newbie

              Good and Bad news... the Firebird XA driver shows that this behavior is not limited to the PostgreSQL pseudo-XA hack.

              19:47:58,564 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257, GlobalId=job.ba.macykids.net//812, BranchQual=] errorCode=XA_UNKNOWN(0)
              javax.transaction.xa.XAException: start called with transaction associated
              at org.firebirdsql.jca.FBManagedConnection.start(FBManagedConnection.java:575)
              at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1180)
              at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1303)
              at org.jboss.tm.TxCapsule.commit(TxCapsule.java:340)
              at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:73)
              at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:319)

              Brian Macy