Message persistence
Persistent messages are written to logs and queue data files. If a queue manager is restarted after a failure, it recovers these persistent messages as necessary from the logged data. Messages that are not persistent are discarded if a queue manager stops, whether the stoppage is as a result of an operator command or because of the failure of some part of your system.
Nonpersistent messages stored in a coupling facility (CF) on z/OS® are an exception to this. They persist as long as the CF remains available.
When you create a message, if you initialize the message descriptor (MQMD) using the defaults, the persistence for the message is taken from the DefPersistence attribute of the queue specified in the MQOPEN command. Alternatively, we can set the persistence of the message using the Persistence field of the MQMD structure to define the message as persistent or nonpersistent.
The performance of our application is affected when we use persistent messages; the extent of the effect depends on the performance characteristics of the machine's I/O subsystem and how we use the sync point options on each platform:
- A persistent message, outside the current unit of work, is written to disk on every put and get operation. See Committing and backing out units of work.
- For all platforms except IBM® i, a persistent message within the current unit of work is logged only when the unit of work is committed, and the unit of work can contain many queue operations.
Nonpersistent messages can be used for fast messaging. See Safety of messages for further information about fast messages.
Note: A combination of writing persistent messages within a unit of work, and writing persistent messages outside a unit or work, can cause potentially severe performance problems for your applications. This is particularly true when the same target queue is used for both operations.