In-doubt units of work

A database might have in-doubt units of work if contact with the queue manager is lost after the database manager has been instructed to prepare. Until the database server receives the outcome from the queue manager (commit or roll back), it needs to retain the database locks associated with the updates.

Because these locks prevent other applications from updating or reading database records, resynchronization needs to take place as soon as possible.

If, for some reason, we cannot wait for the queue manager to resynchronize with the database automatically, we can use facilities provided by the database manager to commit or roll back the database updates manually. In the X/Open Distributed Transaction Processing: The XA Specification, this is called making a heuristic decision. Use it only as a last resort because of the possibility of compromising data integrity; you might, for example, mistakenly roll back the database updates when all other participants have committed their updates.

It is far better to restart the queue manager, or use the rsvmqtrn command when the database has been restarted, to initiate automatic resynchronization.