7 Replies Latest reply on Aug 3, 2009 4:49 AM by Andy Taylor

    Transaction management in JCA adapter is screwed up

    Tim Fox Master

      I just took a look at the tx management code in the JCA adapter, and it looks just plain wrong in places.

      JBMMessageHandler::onMessage.

      Firstly it seems a transaction is *always* being started and committed/rolled back for *every* message. It's my understanding that this should only be done if the bean is using CMT and the transaction atttribute is Required.

      For BMT or transaction attribute=NOT_SUPPORTED no transaction should be created.

      Also

       if (activation.getActivationSpec().getAcknowledgeModeInt() == Session.SESSION_TRANSACTED || activation.getActivationSpec()
       .getAcknowledgeModeInt() == Session.CLIENT_ACKNOWLEDGE)
       {
       try
       {
       message.acknowledge();
       }
       catch (MessagingException e)
       {
       log.error("Failed to process message", e);
       }
       }
      


      The above code is a nonsense, since a) it's illegal to use CLIENT_ACKNOWLEDGE in a MDB and b) if a session is transacted, message.acknowledge() does nothing anyway.

      Also the code in JBMResourceAdapter::createSession seems just plain wrong - it seems to be creating XA sessions when ack mode = auto_ack !! ??

      The specification "EJB core contracts and requirements" Chapter 5 should be read properly and the code in the adapter corrected.

        • 2. Re: Transaction management in JCA adapter is screwed up
          Tim Fox Master

          This is how I think the tx behaviour should be:

          1) CMT, tx=NOT_SUPPORTED, local_optimisation = false:

          MDB should be *non transacted* - it should use the ack mode as specified in the meta data

          2) CMT, tx=NOT_SUPPORTED, local_optimisation = true

          MDB should be *non transacted* - it should use the ack mode as specified in the meta data

          3) CMT, REQUIRED, local_optimisation = false:

          MDB should create a JTA tx *before delivery* and commit at completion of onMessage

          4) CMT, REQUIRED, local_optimisation = true

          MDB should create a *** local tx *** *before delivery* and commit at completion of onMessage

          5) BMT, local_optimisation = false:

          MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)

          6) BMT, local_optimisation = true

          MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)

          • 3. Re: Transaction management in JCA adapter is screwed up
            Andy Taylor Master

            Ive implemented this with the following changes.

            2) CMT, tx=NOT_SUPPORTED, local_optimisation = true

            MDB should be *non transacted* - it should use the ack mode as specified in the meta data


            Ive made this option so that it uses the a local tx, this is to allow the user to run with *only* a single local tx. see next.

            4) CMT, REQUIRED, local_optimisation = true

            MDB should create a *** local tx *** *before delivery* and commit at completion of onMessage


            When 'REQUIRED' is chosen then the container will always create a global tx no matter what. This happens when the call is made to endpoint..onMessage(message) method (endpoint is a proxy and creates the tx before the actual call to the MDB's onMessage). This means that there would be a local proxy and a global proxy. I've left this configurable and i'll explain fully in the docs how local optimization works.


            5) BMT, local_optimisation = false:

            MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)


            The ack mode is always used. The outcome of a user transaction when used in an MDB has no effect on the actual delivery.

            6) BMT, local_optimisation = true

            MDB should be *non transacted* - it should use the ack mode as specified in the meta data (unless a user transaction is started)


            I've allowed the user to be able to use local tx's if they want. because of the reason mentioned for 5). This means that if an exception is thrown from inside the MDb the user can have the message redelivered.


            • 4. Re: Transaction management in JCA adapter is screwed up
              Tim Fox Master

              Are you allowing Clebert's suggestion of batching too?

              • 5. Re: Transaction management in JCA adapter is screwed up
                Andy Taylor Master

                yeah, I'm going to do that

                • 6. Re: Transaction management in JCA adapter is screwed up
                  Tim Fox Master

                  Great, I noticed this task is marked as complete. Does that mean batching is done too?

                  If so, how is it configured?

                  • 7. Re: Transaction management in JCA adapter is screwed up
                    Andy Taylor Master

                     

                    Great, I noticed this task is marked as complete. Does that mean batching is done too?


                    No, I've just posted separately on this.