Considerations when contact is lost with the XA resource manager
The queue manager tolerates database managers not being available. This means we can start and stop the queue manager independently from the database server. When contact is restored, the queue manager and database resynchronize. We can also use the rsvmqtrn command to manually resolve in-doubt units of work.
In normal operations, only a minimal amount of administration is necessary after you have completed the configuration steps. The administration job is made easier because the queue manager tolerates database managers not being available. In particular this means that:- The queue manager can start at any time without first starting each of the database managers.
- The queue manager does not need to stop and restart if one of the database managers becomes unavailable.
This allows you to start and stop the queue manager independently from the database server.
Whenever contact is lost between the queue manager and a database, they need to resynchronize when both become available again. Resynchronization is the process by which any in-doubt units of work involving that database are completed. In general, this occurs automatically without the need for user intervention. The queue manager asks the database for a list of units of work that are in doubt. It then instructs the database to either commit or roll back each of these in-doubt units of work.
When a queue manager starts, it resynchronizes with each database. When an individual database becomes unavailable, only that database needs to be resynchronized the next time that the queue manager notices it is available again.
The queue manager regains contact with a previously unavailable database automatically as new global units of work are started with MQBEGIN. It does this by calling the xa_open function in the database client library. If this xa_open call fails, MQBEGIN returns with a completion code of MQCC_WARNING and a reason code of MQRC_PARTICIPANT_NOT_AVAILABLE. We can retry the MQBEGIN call later.
Do not continue to attempt a global unit of work that involves updates to a database that has indicated failure during MQBEGIN. There will not be a connection to that database through which updates can be made. Your only options are to end the program, or to retry MQBEGIN periodically in the hope that the database might become available again.
Alternatively, we can use the rsvmqtrn command to resolve explicitly all in-doubt units of work.
- In-doubt units of work
- Display outstanding units of work with the dspmqtrn command
We can use the dspmqtrn command with the -i parameter to display internally originated indoubt transactions. - Resolving outstanding units of work with the rsvmqtrn command
Outstanding units of work complete when the queue manager and Db2 resynchronize. - Mixed outcomes and errors
Although the queue manager uses a two-phase commit protocol, this does not completely remove the possibility of some units of work completing with mixed outcomes. This is where some participants commit their updates and some back out their updates. - Change configuration information
After the queue manager has successfully started to coordinate global units of work, do not change any of the resource manager configuration information.
Parent topic: Scenario 1: Queue manager performs the coordination