4 Replies Latest reply on Aug 8, 2002 10:06 AM by Andreas Mueller

    StdServersession too late for transaction?

    Michael Bartmann Newbie

      I have successfully integrated our companies
      message service to be used by jboss (ProviderAdapter...)

      Now I have implemented XA-support, and have a problem:

      In the StdServerSession of jboss a new transaction is begun
      in the onMessage() method, NOT in the start()-method, so
      my XASession is enlisted after it consumed the message and
      called the onMessage() method.

      Of course only one transaction in the start() method could
      not cope with multiple onMessage() invocations, but the
      only reason for enlisting the JMS-XASession is to roll
      back the "consumation", isn't it?

      In my opinion the XASession should begin the transaction,
      but if does, the StdServerSession fails, because it does
      not use an already existing transaction.

      Isn't the tm.begin() too late in StdServerSession?
      Am I something missing here?
      Or should I really provide my own ServerSession?

        • 1. Re: StdServersession too late for transaction?
          Michael Bartmann Newbie

          Or should the XARessource.start(...) method be implemented
          in such a way that it "picks up" the work done after
          the last commit?

          This not my understanding of the XARessource`s
          responsibilities.

          What do you think?

          • 2. Re: StdServersession too late for transaction?
            Andreas Mueller Newbie

            > In the StdServerSession of jboss a new transaction is
            > begun
            > in the onMessage() method, NOT in the start()-method,
            > so
            > my XASession is enlisted after it consumed the
            > message and
            > called the onMessage() method.

            That's correct. The actual message consumption is done from the ConnectionConsumer outside the tx and the association to the actual XASession must be done from the provider during XAResource.start() which is called within the sessionListener's onMessage() call.

            > Isn't the tm.begin() too late in StdServerSession?
            > Am I something missing here?

            If the tx were started in the serverSession.start() method, you would not be able to load a serverSession with multiple messages. According to the EJB spec, each message has to be delivered in a distinct tx context and thus the XAResource must be enlisted during the sessionListener.onMessage() call. If you provider has a problem with that, it is probably not compliant here.

            -- Andreas

            • 3. Re: StdServersession too late for transaction?
              Michael Bartmann Newbie

              Thank you Andreas, I think I got your point.

              The ServerSession must of course
              have a separate transaction
              for each onMessage()-invocation.
              But the reason to enlist the XASession in this
              transaction is to allow rollback of the
              message consumption.

              So now I modified my XASession/XARessource to
              allow getting enlisted AFTER the consumption was done.

              This works now (!), so perhaps I should shut up, but
              then again there is something I don't understand
              about this:

              Is this semantic of an enlist()-call ("picking up work
              done before") compliant with XARessoure in general or is
              it only ok when the XASession is used in "application
              server mode".

              In my understanding so far an XARessource should throw a
              XAException(XAException.XAER_OUTSIDE) if work had been
              done before the XARessource.start(xid).

              Any comments about this?

              -- Michael

              PS.: Shouldn't the StdServerSession use an already existing
              tx anyway?

              • 4. Re: StdServersession too late for transaction?
                Andreas Mueller Newbie

                > Is this semantic of an enlist()-call ("picking up
                > work
                > done before") compliant with XARessoure in general or
                > is
                > it only ok when the XASession is used in
                > "application
                > server mode".

                This semantic applies in conjunction with a connection consumer. Without that (e.g. calling receive) you have to enlist the XAResource before message consumption.

                A connection consumer consumes messages outside of any tx, picks up a server session from the pool, loads the associated JMS session with messages and calls run. The JMS session is responsible to deliver each message in their own XA tx, thus, it must associate the message to the XA tx before it is actually delivered to the MDB. One way to implement it is to watch when the XAResource gets enlisted (start) and do the association here (the way JBoss/JBossMQ/SwiftMQ does it), another way is to use call backs from the app server (beforeDelivery/afterDelivery) (the way the JMS RI does it). The implementation isn't specified anywhere, only the semantic (single tx) is.

                > In my understanding so far an XARessource should
                > throw a
                > XAException(XAException.XAER_OUTSIDE) if work had
                > been
                > done before the XARessource.start(xid).

                But it hasn't be done. The tx is started, the message is associated, XAResource.start returns. Everything is ok.

                -- Andreas