Non-Persistent Messages

Non-persistent messages are IBM MQ's fast lane: the queue manager accepts your put without promising to durably log every byte to disk first. That cuts latency and log I/O, which matters when you send thousands of small updates per second. The trade-off is explicit—if the queue manager stops abruptly, non-persistent messages that were only in memory or not yet fully protected can disappear. Beginners often assume MQ never loses anything; understanding non-persistence is how you avoid designing a payment flow on telemetry settings. This page explains MQPER_NOT_PERSISTENT, DEFPSIST(NO), how puts and gets interact with syncpoint, performance on distributed and z/OS queue managers, channel behavior, monitoring, and when architects choose non-persistent messages despite the risk.

How Non-Persistence Works Inside the Queue Manager

When an application issues MQPUT, the queue manager evaluates the effective persistence from the message descriptor (MQMD) Persistence field and the queue's DEFPSIST default. For MQPER_NOT_PERSISTENT, the queue manager places the message on the queue without the same durable logging path used for MQPER_PERSISTENT. The put can return success once the message is visible to getters according to the implementation—meaning your application may continue while the message still faces risk if power fails milliseconds later. On a controlled shutdown, more data may flush, but you must not rely on that for design. Persistent messages, by contrast, are written through the log so a restart can recover them. Non-persistent is not a bug; it is a deliberate performance contract.

Application and JMS Equivalents

In the MQI (Message Queue Interface), set Persistence in the MQMD before MQPUT or MQPUT1. In Java JMS, DeliveryMode.NON_PERSISTENT maps to the same idea. .NET and other clients expose similar flags. If you leave persistence as MQPER_PERSISTENCE_AS_Q_DEF, the queue attribute alone decides—operations teams often set DEFPSIST on queues so developers cannot accidentally persist huge volumes on a telemetry queue, or conversely set DEFPSIST(YES) on financial queues so a forgotten flag still protects data. Document the precedence rule in your integration standards: application override usually wins over DEFPSIST when explicitly set, but verify against your MQ version and client library documentation.

Performance: Why Teams Choose Non-Persistent

Persistent puts wait for log forces (subject to SYNCPOINT and platform tuning). Non-persistent puts skip much of that cost. In benchmark terms you might see multiples of throughput on the same hardware—real numbers depend on message size, disk subsystem, LOG settings, and whether puts are syncpointed. On z/OS, non-persistent traffic still consumes CPU and coupling facility resources but avoids persistent log records for those messages. Capacity planners use non-persistent streams to protect the log from being flooded by metrics while keeping ORDERS.* queues persistent. The mistake is applying that tuning to money movement because the queue name looked similar.

• Lower latency per put for small messages.
• Reduced log write volume and archive growth.
• Less disk pressure on high-volume fan-out.
• Higher effective messages-per-second on the same QM.

Syncpoint and Non-Persistent Messages

Syncpoint (MQCMIT and MQBACK) groups messaging operations into a unit of work. A non-persistent put under syncpoint can still be rolled back before commit—other applications will not see it. After commit, the message is available to consumers, but it remains non-persistent for restart purposes. Coordinating a database update with a non-persistent MQPUT in one syncpoint does not make the message durable across a crash; it only makes the put atomic with other resources until commit or backout. For two-phase business outcomes that must survive failure, use persistent messages (and understand at-least-once consumer behavior covered in later tutorials).

Channels, XMITQ, and Remote Puts

When a message routes through a sender channel, non-persistent data on the transmission queue faces the same crash risk as locally. If the channel is in flight and the sending queue manager fails, in-transit non-persistent messages may not appear on the partner. Remote queue definitions do not change persistence; the application or DEFPSIST still sets it. Enterprise patterns often mandate DEFPSIST(YES) on transmission-related queues or require applications to set persistent for cross-datacenter traffic while using non-persistent only inside a single queue manager for local fan-out.

Operational Monitoring

1. Review queue DEFPSIST with DISPLAY QLOCAL—all business-critical queues should be YES unless architecturally approved.
2. Sample application MQMD settings in test; logging Persistence on put in trace helps audits.
3. Alert on unexpected depth growth on non-persistent queues after incidents—backlog may be incomplete after recovery.
4. Document which interfaces are allowed NON_PERSISTENT in your integration catalog.

Tutorial: Lab MQSC for a Telemetry Queue

1
2
3
4
5
6
7
8
9
* Queue tuned for high-volume, loss-tolerant metrics
DEFINE QLOCAL('METRICS.CPU') REPLACE +
  DEFPSIST(NO) MAXDEPTH(500000) MAXMSGL(4096)
* Application put with explicit non-persistent (conceptual MQI):
*   MD.Persistence = MQPER_NOT_PERSISTENT
*   CALL MQPUT(Hconn, Hobj, MD, PMO, buflen, buffer)
* Compare: business queue with safe default
DEFINE QLOCAL('ORDERS.IN') REPLACE DEFPSIST(YES)
DISPLAY QLOCAL('METRICS.CPU') DEFPSIST CURDEPTH

Design Checklist: Persistent vs Non-Persistent

Ask four questions before marking a flow non-persistent: (1) If the message vanishes on crash, is revenue or compliance harmed? (2) Will another message or system replace the lost data soon? (3) Is duplicate delivery worse than occasional loss? (4) Does operations accept explaining loss to auditors? If any answer points to durability, use persistent messages and idempotent consumers instead of non-persistent puts.

Explain Like I'm Five: Non-Persistent Messages

You shout today's lunch menu across the playground. Your friend hears it and writes it on the chalkboard (they got the message). If the bell rings and everyone runs inside in a panic, nobody wrote the menu in the school diary—tomorrow you might forget what you said (lost on crash). Writing it in the diary first is like a persistent message: slower, but the words survive even if everyone scrambles.

Practice Exercises

Exercise 1: Override Precedence

Queue METRICS.CPU has DEFPSIST(NO). Application sets MQPER_PERSISTENT. What persistence applies? Explain why operations might still be unhappy.

Exercise 2: Channel Policy

A bank sends non-persistent payment hints across a WAN channel. List three failure modes and whether persistent messages would help.

Exercise 3: Capacity

Estimate log impact if 50,000 small persistent puts per second move to non-persistent on one queue manager. What else must you monitor?

Frequently Asked Questions

Test Your Knowledge