Messages have a quality of service attribute that specifies the reliability of message delivery. You can select a reliability to suit your requirements for assured delivery, and system performance.
For non-transactional JMS message-driven beans and MessageListeners that use a JMS destination configured on the default messaging provider, best-effort nonpersistent messages are not recoverable. In this case, if a message is unlocked because the message-driven bean or MessageListener threw an exception, then the message is not redelivered or sent to the exception destination because it was deleted from the message store when it was passed to the listener. If you require higher message reliability for non-transactional JMS message-driven beans and MessageListeners, configure a different option for the Maximum reliability property of the bus destination.
Messages: | Messages survive: | ||||||||
---|---|---|---|---|---|---|---|---|---|
Reliability | JMS delivery mode | Transactionally atomic | Hardened? | Discarded in normal operation? | Duplicated? | Planned shutdown | Client comms failure | Engine comms failure | Engine crash |
best effort nonpersistent | Nonpersistent | No, individual messages can be discarded | No | Yes | No | No | No | No | No |
express nonpersistent | Nonpersistent | Yes; messages are not discarded and never survive server restart | Only as a result of resource shortage | No | Possibly; state data can be lost on server crash resulting in duplication | No | No | Yes | No |
reliable nonpersistent | Nonpersistent | Yes; messages are not discarded and never survive server restart | Only as a result of resource shortage | No | Possibly; state data can be lost on server crash resulting in duplication | No | Yes | Yes | No |
reliable persistent | Persistent | Yes | Yes; asynchronously | No | Possibly; as deletion from the database is asynchronous with respect to user requests | Yes; hardened messages are recovered, planned shutdown hardens cached messages | Yes | Yes | Possibly; hardened messages are recovered |
assured persistent | Persistent | Yes | Yes; synchronously | No | No | Yes | Yes | Yes | Yes |
Messages of reliable persistent reliability are written to disk , but this is done asynchronously with respect to the producing application. This allows increased flexibility in scheduling and batching of database updates, which can be used to increase throughput. However, messages might be lost if a messaging engine fails before this asynchronous write is complete, but will not be lost under normal operating conditions.
Messages of assured persistent reliability are written to disk synchronously with respect to the producing application.
The administrator can specify the reliability setting on bus destinations (including foreign destinations and alias destinations) or the reliability can be specified by individual producers (typically under application control through an API call). The administrator can specify whether the default reliability for the destination can be overridden by a producer, and the maximum reliability that attached producers can request. For alias destinations, the administrator can specify that the reliability setting is inherited from the target destination.
For topologies that include a WebSphere MQ link the administrator must map the reliability settings for bus destinations to the equivalent delivery options in WebSphere MQ.