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.
|
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.