Home
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 your database product for details.
Why is the dynamic registration optimization useful? In your 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, your application calls xa_open during the first MQBEGIN call on a WebSphere 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 WebSphere 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 WebSphere 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 WebSphere MQ when it has performed a persistent update that it wants to be included in the current global unit of work. WebSphere MQ provides the ax_reg function for this purpose.
The database's client code that runs in your 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, WebSphere MQ records that the database has participated. If this is the first ax_reg call on this WebSphere 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
Parent topic:
Scenario 1: Queue manager performs the coordination
fa13870_
Home