WebSphere WebSphere Application Server Express, Version 6.0.x Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Message reliability levels

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.

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 may 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 may 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 may be discarded when a messaging engine fails.
assured persistent
Messages are not discarded.
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:
  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
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 above description of best effort nonpersistent for details of how messages may be lost) other messages being processed in the same transaction may 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. System performance is affected by the frequency with which messages are written to disk. Messages of best effort nonpersistent reliability are never written to disk, express nonpersistent and reliable nonpersistent messages are only written if the system is exhibiting resource shortage, 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. 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.

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.

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.

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 bus destination
Related reference
Mapping of message delivery options flowing through the WebSphere MQ link

Concept topic

Terms of Use | Feedback

Last updated: 2 Aug 2005
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.pmc.express.doc\concepts\cjj9000_.html

© Copyright IBM Corporation 2004, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)