Messages have a quality of service attribute that you can use to
specify how reliable message delivery will be. When configuring reliability
levels you must take your system requirements into account, for example, you
can set assured delivery if you want messages to be delivered under any circumstances,
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
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.
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, at server
restart, or when there is 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:
|
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 |
Only as a result of resource shortage |
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 |
Only as a result of resource shortage |
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 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.
- 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 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.