Message reliability levels

Messages have a quality of service attribute that you can use to specify how reliable message delivery will be. When you configure reliability levels, you need to consider the requirements of your system. For example, if you want messages to be delivered under any circumstances, you can set assured delivery, and you can specify how the system will handle a large amount of transactions.

You can specify the following reliability options (also known as delivery options) for messages. They are listed in order of increasing reliability.
Best effort nonpersistent
Messages are discarded when a messaging engine stops or fails. Messages might also be discarded if a connection used to send them becomes unavailable and as a result of constrained system resources.

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.

Express nonpersistent
Messages are discarded when a messaging engine stops or fails. Messages might also be discarded if a connection used to send them becomes unavailable.
Reliable nonpersistent
Messages are discarded when a messaging engine stops or fails.
Reliable persistent
Messages might be discarded when a messaging engine fails.
Assured persistent
Messages are not discarded.
Important: If you change the delivery reliability options of a message sent by a JMS application from one of the Persistent message reliability options (Assured persistent and Reliable persistent) to one of the Nonpersistent message reliability options (Best effort nonpersistent, Express nonpersistent, Reliable nonpersistent), you risk losing messages in certain circumstances. For example, you risk losing messages at server restart, or when there is a heavy workload.
There is a trade-off between reliability of message delivery and the speed with which messages are delivered. The following table illustrates the behavior associated with the five levels of reliability and will help you choose the required level.
Note: In addition to setting your selected reliability level, in order for messages to survive the various failures shown in the table with certain reliability, your application must be transactional.
Table 1. The five levels of reliability
  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 Backup and restore
Best effort nonpersistent Nonpersistent No, individual messages can be discarded No Yes No No No No No No
Express nonpersistent Nonpersistent Yes: messages are not discarded and never survive server restart Possibly: when messages build up on a destination No Possibly: state data can be lost on server crash resulting in duplication No No Yes No No
Reliable nonpersistent Nonpersistent Yes: messages are not discarded and never survive server restart Possibly: when messages build up on a destination No Possibly: state data can be lost on server crash resulting in duplication No Yes Yes No 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 Possibly: hardened messages can be backed up and recovered
Assured persistent Persistent Yes Yes: synchronously No No Yes Yes Yes Yes Yes
The following provides an explanation of the column headings in the table:
JMS delivery mode
For JMS objects such as connection factories and destinations, the mapping between JMS delivery mode and the reliability settings. The default mapping for the JMS nonpersistent delivery mode is express nonpersistent. The default mapping for the JMS persistent delivery mode is reliable persistent.
Transactionally atomic
Whether the message is atomic with respect to other messages produced or consumed within the same transaction. Best effort messages are not transactionally atomic at the time that they are produced with respect to other messages, so if one such message is lost (see the description of best effort nonpersistent earlier in this topic for details of how messages might be lost), other messages being processed in the same transaction might still be delivered successfully when the transaction commits (if the transaction is rolled back, all operations on messages, irrespective of their reliability, are rolled back). For messages of higher reliability, if a failure occurs that would cause the loss of one of the messages in the transaction, the transaction, and all work being performed under that transaction, will be rolled back, making the operation transactionally atomic.
Hardened?
Whether messages are written to disk in the data store or the file store. System performance is affected by the frequency with which messages are written to disk, and in general using a file store for your messaging engine can improve performance. Messages of best effort nonpersistent reliability are never written to disk, express nonpersistent and reliable nonpersistent messages are written if messages build up on a destination, while reliable persistent and assured persistent messages are always written to disk.

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. Messages are not lost under normal operating conditions, but messages might be lost if a messaging engine fails before this asynchronous write is complete.

Messages of assured persistent reliability are written to disk synchronously with respect to the producing application.

If messages are allowed to build up on a destination due to them not being consumed as quickly as they are produced, a messaging engine may choose to write messages to disk in order to manage memory usage.

When any message whose quality of service attribute is better than best effort nonpersistent is written to a disk, it may also be cached in a memory buffer.

Discarded in normal operation?
Whether messages are discarded during normal operation. This does not include planned shutdown.
Duplicated?
Whether messages are duplicated following a server crash.
Planned shutdown
Whether messages survive a planned shutdown or startup.
Client comms failure
Whether messages survive the failure of client-messaging engine communication.
Engine comms failure
Whether messages survive the failure of inter-engine communication.
Engine crash
Whether messages survive the crash of a messaging engine or a server.
Backup and restore
Whether messages survive an online backup and restore process.

The administrator can specify the reliability setting on bus destinations (including foreign destinations and alias destinations), or individual producers can specify the reliability (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.




Related concepts
Considerations when choosing between a file store and a data store
The service integration environment backup
Transaction support in WebSphere Application Server
Learning about service integration buses
Related tasks
Creating a bus destination
Creating a queue for point-to-point messaging
Creating a topic space for publish/subscribe messaging
Creating an alias bus destination
Creating a foreign destination on a bus
Controlling the memory buffers used by a messaging engine
Related reference
Mapping of message delivery options flowing through the WebSphere MQ link
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 4:28:44 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-mp&topic=cjj9000_
File name: cjj9000_.html