Messages that are backed out

 

When processing messages from a queue under the control of a unit of work, the unit of work can consist of one or more messages. If a backout occurs, the messages that were retrieved from the queue are reinstated on the queue, and they can be processed again in another unit of work. If the processing of a particular message is causing the problem, the unit of work is backed out again. This can cause a processing loop. Messages that were put to a queue are removed from the queue.

An application can detect messages that are caught up in such a loop by testing the BackoutCount field of MQMD. The application can either correct the situation, or issue a warning to an operator.

In WebSphere MQ for z/OS, to ensure that the backout count survives restarts of the queue manager, set the HardenGetBackout attribute to MQQA_BACKOUT_HARDENED; otherwise, if the queue manager has to restart, it does not maintain an accurate backout count for each message. Setting the attribute this way adds the penalty of extra processing.

On WebSphere MQ for iSeries, WebSphere MQ for Windows, and WebSphere MQ on UNIX systems, the backout count always survives restarts of the queue manager. Any change to the HardenGetBackout attribute is ignored.

For more information on committing and backing out messages, see Committing and backing out units of work.

 

Parent topic:

WebSphere MQ messages

fg10840_