2 Replies Latest reply on Jun 8, 2005 6:04 AM by Felipe Carretero

    JCA 1.5 development

    Felipe Carretero Newbie

      Hi all,

      I'm trying to write a JCA based on the 1.5 spec. I'm trying to follow Hiram's advice for developing a resource adapter for MQSeries with XA capabilities.

      Instead of using

      to read the messages, I'm creating an infinite loop for polling a queue (JMS) with
      consumer.receive(tx timeout)
      Using this procedure, I'm able to start a transaction. This is developed using the work management contract.

      The problems that I'm having are:
      - When I shutdown JBoss, the MDB is never finishing the undeployment.
      - After reading the message when I'm trying to write the message to another queue, it never finishes creating the session
      connection.createQueueSession (responseTransacted, QueueSession.AUTO_ACKNOWLEDGE);

      I would like to know if this is a good approach.


        • 1. Re: JCA 1.5 development
          Felipe Carretero Newbie

          Hi all,

          I think I'm getting closer. I have tried to make a transaction with 2 resources MQSeries & Oracle. I works perfectly.
          I think the problem is that when I try to make a transaction using 1 resource, the transaction manager is starting the resource twice. It's not identifying that it should use "1 phase commit".

          How could I check that what I'm saying is true?. And, more important, how could I solve this problem.



          • 2. Re: JCA 1.5 development
            Felipe Carretero Newbie

            Hi all again,

            I have gone one step further. I have read some documentation "WebSphere MQ XA support and Tuxedo" where it says

            It is possible for WebSphere MQ on Windows and UNIX systems to block
            Tuxedo-coordinated XA applications indefinitely in xa_start. This can occur only
            when two or more processes coordinated by Tuxedo in a single global transaction
            attempt to access WebSphere MQ using the same transaction branch ID, or XID. If
            Tuxedo gives each process in the global transaction a different XID to use with
            WebSphere MQ, this cannot occur.
            To avoid the problem, configure each application in Tuxedo that will access
            WebSphere MQ under a single global transaction ID (gtrid), within its own Tuxedo
            server group. Processes in the same server group use the same XID when accessing
            resource managers on behalf of a single gtrid, and are therefore vulnerable to
            blocking in xa_start in WebSphere MQ. Processes in different server groups use
            separate XIDs when accessing resource managers and so will not have to worry
            about serializing their transaction work in WebSphere MQ.

            I have seen the following in the TransactionManagerImpl.enlistResource() code:

            // The xaRes is new. We register the xaRes with the Xid
            // that the RM has previously seen from this transaction,
            // and note that it has the same RM.
            resource = addResource(xaRes, resource.getXid(), resource);
            return resource.startResource();

            How could I avoid this problem.