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.