XA dynamic registration

The XA specification provides a way of reducing the number of xa_* calls that a transaction manager makes to a resource manager. This optimization is known as dynamic registration.

Dynamic registration is supported by Db2 . Other databases might support it; consult the documentation for the database product for details.

Why is the dynamic registration optimization useful? In the application, some global units of work might contain updates to database tables; others might not contain such updates. When no persistent update has been made to a database's tables, there is no need to include that database in the commit protocol that occurs during MQCMIT.

Whether or not your database supports dynamic registration, the application calls xa_open during the first MQBEGIN call on an IBM MQ connection. It also calls xa_close on the subsequent MQDISC call. The pattern of subsequent XA calls depends on whether the database supports dynamic registration:

    If your database does not support dynamic registration...
    Every global unit of work involves several XA function calls made by IBM MQ code into the database client library, regardless of whether you made a persistent update to the tables of that database within your unit of work. These include:

    • xa_start and xa_end from the application process. These are used to declare the beginning and end of a global unit of work.
    • xa_prepare, xa_commit, and xa_rollback from the queue manager agent process, amqzlaa0. These are used to deliver the outcome of the global unit of work: the commit or rollback decision.

    In addition, the queue manager agent process also calls xa_open during the first MQBEGIN.

    If your database supports dynamic registration...
    The IBM MQ code makes only those XA function calls that are necessary. For a global unit of work that has not involved persistent updates to database resources, there are no XA calls to the database. For a global unit of work that has involved such persistent updates, the calls are to:

    • xa_end from the application process to declare the end of the global unit of work.
    • xa_prepare, xa_commit, and xa_rollback from the queue manager agent process, amqzlaa0. These are used to deliver the outcome of the global unit of work: the commit or rollback decision.

For dynamic registration to work, it is vital that the database has a way of telling IBM MQ when it has performed a persistent update that it wants to be included in the current global unit of work. IBM MQ provides the ax_reg function for this purpose.

The database's client code that runs in the application process finds the ax_reg function and calls it, to dynamically register the fact it has done persistent work within the current global unit of work. In response to this ax_reg call, IBM MQ records that the database has participated. If this is the first ax_reg call on this IBM MQ connection, the queue manager agent process calls xa_open.

The database client code make this ax_reg call when it is running in your process, for example, during an SQL UPDATE call or whatever call in the database's client API is responsible

  • Error conditions
    In XA dynamic registration there is a possibility of a confusing failure in the queue manager.
  • Summarizing XA calls
    Here is a list of the calls that are made to the XA functions in a database client library as a result of the various MQI calls that control global units of work. This is not a complete description of the protocol described in the XA specification; it is provided as a brief overview.

Parent topic: Scenario 1: Queue manager performs the coordination