IBM Support

IT38380: Unable to use nested XA transactions with Mule and the Bitronix transaction manager.

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • An MQ 9.2.0.2 classes for JMS application is running in a Mule
    environment, which uses Bitronix as the transaction manager.
    
    The application has been set up to use nested XA transactions.
    These are XA transactions where an outer transaction gets
    suspended so that another transaction (known as an inner
    transaction) can be performed. Once the inner transaction has
    finished, the outer transaction is resumed.
    
    When the application is run, the outer transaction is suspended
    successfully. However, once the inner transaction has completed,
    the outer one cannot be resumed. This is because the
    implementation of the XAResource.isSameRM(...) method provided
    by the MQ classes for JMS has been hard-coded to return false.
    
    Here is an extract from an MQ classes for JMS trace that shows
    this:
    
    [16/06/21 10:39:11.380.00] 00000013 @5ba9abb5
    c.i.mq.jmqi.JmqiXAResource { isSameRM(XAResource)
    [c.i.mq.jmqi.JmqiXAResource@5ba9abb5]
    [16/06/21 10:39:11.380.01] 00000013 @5ba9abb5
    c.i.mq.jmqi.JmqiXAResource } isSameRM(XAResource) returns
    [false] Boolean
    
    In these trace points:
    
    - The isSameRM(XAResource) method is called on the object
    JmqiXAResource@5ba9abb5.
    - And the same object (JmqiXAResource@5ba9abb5) is passed into
    the method, so the method should return true.
    

Local fix

  • An interim fix is available
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects users of:
    
    - The MQ 9.2 classes for JMS.
    - The MQ 9.2 resource adapter.
    
    who have applications running within an environment that has
    been configured to use the Bitronix transaction manager to
    manage XA transactions.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    When using XA transactions in Java, a transaction manager will
    create an XAResource object, which represents the resource
    manager that is involved in the transaction. Whenever the
    transaction manager needs to communicate with the resource
    manager, it calls various methods on the XAResource. The
    XAResource then flows the corresponding XA calls to the resource
    manager, collects the responses and passes them back up to the
    transaction manager.
    
    The Bitronix transaction manager provides support for nested XA
    transactions. When an application wants to use a nested XA
    transaction, the Bitronix transaction manager will:
    
    - Suspend the outer XA transaction.
    - Perform the inner XA transaction.
    - Resume the outer XA transaction.
    
    Prior to resuming the outer XA transaction, the Bitronix
    transaction manager calls the method:
    
    XAResource.isSameRM(XAResource)
    
    to confirm that the XAResource being used to resume the outer
    transaction is the same as the XAResource object which was used
    to suspend it. If the method returns true, then the outer
    transaction is resumed. However, if the method returns false,
    then the transaction manager assumes that there is an issue with
    resuming the outer transaction, and prevents it from restarting.
    
    
    In the MQ classes for JMS and resource adapter, the
    implementation of the method:
    
    XAResource.isSameRM(XAResource)
    
    was hard coded to always return false, as it had been found that
    providing a proper implementation of the method would result in
    certain transaction managers making a series of XA calls which
    resulted in an MQ queue manager generating an FDC. This meant
    that it was not possible to for applications that used either
    the MQ classes for JMS or the MQ resource adapter with the
    nested XA transaction functionality provided by the Bitronix
    transaction manager.
    

Problem conclusion

  • To resolve this issue, some new functionality has been added to
    the MQ classes for JMS and MQ resource adapter so that, when
    running in an environment that has been configured to use the
    Bitronix transaction manager, the
    XAResource.isSameRM(XAResource) method will check that the
    XAResource object passed in is connected to the same queue
    manager as the XAResource object that the method is being called
    on.
    
    If both XAResource objects are connected to the same queue
    manager, then the method will return true. However, if the two
    XAResource objects are connected to different queue managers,
    then the method will return false. This allows the Bitronix
    transaction manager to correctly resume nested XA transactions
    where required.
    
    To enable the new functionality, the application using the
    Bitronix transaction manager must be started with the following
    Java system property set:
    
    -Dcom.ibm.mq.cfg.jmqi.xaTransactionManager=bitronix
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v9.2 LTS   9.2.0.5
    v9.x CD    9.2.5
    
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
    
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
    ---------------------------------------------------------------
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT38380

  • Reported component name

    MQ BASE V9.2

  • Reported component ID

    5724H7281

  • Reported release

    920

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2021-09-15

  • Closed date

    2021-10-14

  • Last modified date

    2021-10-14

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    MQ BASE V9.2

  • Fixed component ID

    5724H7281

Applicable component levels

[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"920"}]

Document Information

Modified date:
18 October 2021