Ensuring that messages are not lost

Messages that are generated by your applications and by runtime components for inter-component communication are important to the operation of your integration nodes.

For messages traveling across WebSphere® MQ, two techniques can protect against message loss:

• Message persistence

  If a message is persistent, WebSphere MQ ensures that it is not lost when a failure occurs, by copying it to disk.

• Sync point control

  An application can request that a message is processed in a synchronized unit-of-work (UOW)

For more information about how to use these options, refer to the System Administration Guide section of the WebSphere MQ Version 7.5 product documentation online.

If delivery of application messages is critical, you must design application programs and the message flows that they use to ensure that messages are not lost. The techniques used depend on the protocol used by the applications.

WebSphere MQ Enterprise Transport

If you are using the built-in input nodes that accept messages across the WebSphere MQ protocol, you can use the following guidelines and recommendations:

• Using persistent messages

  WebSphere MQ messaging products provide message persistence, which defines the longevity of the message in the system and guarantees message integrity. Nonpersistent messages are lost in the event of system or queue manager failure. Persistent messages are always recovered if a failure occurs.

  You can control message persistence in the following ways:

  • Program your applications that put messages to a queue using the MQI or AMI to indicate that the messages are persistent.
  • Define the input queue with message persistence as the default setting.
  • Configure the output node to handle persistent messages.
  • Program your subscriber applications to request message persistence.

  When an input node reads a message from an input queue, the default action is to use the persistence defined in the WebSphere MQ message header (MQMD), that has been set either by the application creating the message, or by the default persistence of the input queue. The message retains this persistence throughout the message flow, unless it is changed in a subsequent message processing node.

  You can override the persistence value of each message when the message flow terminates at an output node. This node has a property that allows you to specify the message persistence of each message when it is put to the output queue, either as the required value, or as a default value. If you specify the default, the message takes the persistence value defined for the queues to which the messages are written.

  If a message passes through a Publication node, the persistence of messages sent to subscribers is determined by the registration options of the subscribers. If a subscriber has requested persistent message delivery, and is authorized to do so by explicit or implicit (inherited) ACL, the message is delivered persistently regardless of its existing persistence property. Also, if the user has requested nonpersistent message delivery, the message is delivered nonpersistent regardless of its existing persistence property.

  If a message flow creates a message (for example, in a Compute node), the persistence in the MQMD of the new message is copied from the persistence in the MQMD of the incoming message.

• Processing messages under sync point control

  The default action of a message flow is to process incoming messages under sync point in a transaction that is controlled by the integration node. This means that a message that fails to be processed for any reason is backed out by the integration node. Because it was received under sync point, the failing message is reinstated on the input queue and can be processed again. If the processing fails, the error handling procedures that are in place for this message flow (defined either by how you have configured the message flow, or by the integration node) are executed.

WebSphere MQ Web Services Transport

If you are using the HTTPInput, HTTPRequest, SOAPInput, SOAPRequest nodes, or a SOAPAsyncRequest and SOAPAsyncResponse node pair that accept messages from web services applications, no facilities are available to protect against message loss. You can, however, provide recovery procedures by configuring the message flow to handle its own errors.

Other transports and protocols

If you have created your own user-defined input nodes that receive messages from another transport protocol, you must rely on the support provided by that transport protocol, or provide your own recovery procedures.