How consistency is maintained after an abnormal termination
When a queue manager is restarted after an abnormal termination, it must
determine whether to commit or to back out units of recovery that were active
at the time of termination. For some units of recovery, WebSphere MQ has enough
information to make the decision. For others, it does not, and must get information
from the coordinator when the connection is reestablished.
Figure 14 shows four periods within the two phases:
a, b, c, and d. The status of a unit of recovery depends on the period in
which termination happened. The status can be one of the following:
- In flight
- The queue manager ended before finishing phase 1 (period a or b); during
restart, WebSphere MQ backs out the updates.
- In doubt
- The queue manager ended after finishing phase 1 and before starting
phase 2 (period c); only the coordinator knows whether the error happened
before or after the commit (point 9). If it happened before, WebSphere MQ must back
out its changes; if it happened after, WebSphere MQ must make its changes and commit
them. At restart, WebSphere MQ waits for information from the coordinator before
processing this unit of recovery.
- In commit
- The queue manager ended after it began its own phase 2 processing (period
d); it makes committed changes.
- In backout
- The queue manager ended after a unit of recovery began to be backed
out but before the process was complete (not shown in the figure); during
restart, WebSphere MQ continues to back out the changes.