Messages have a quality of service attribute that you can
use to specify how reliable message delivery will be. JMS applications
send messages with a JMS delivery mode (persistent or nonpersistent),
then service integration uses JMS connection factory settings to map
the JMS delivery mode to a service integration message reliability
setting. Additional settings on bus destinations (including foreign
destinations and alias destinations) can override this message reliability.
Note: The term message reliability level corresponds to all of the
following terms:
- Quality of service (QoS) (service integration messaging)
- Delivery mode (JMS)
- Persistence (
WebSphere® MQ )
You can specify the following service integration message reliability
levels for messages. The options 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 or as a result of constrained system resources.
-
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.
Note: Higher levels of reliability have higher impacts on
performance.
JMS applications send messages with a JMS delivery mode (persistent or nonpersistent).
Applications specify this delivery mode as a parameter of the JMS send() method,
but you can optionally specify a delivery mode that overrides the send() method
as an attribute of the JMS destination.
Service integration uses the JMS connection factory settings to
map the JMS delivery modes (persistent and nonpersistent) to service
integration message reliability levels. You can use this mapping to
choose between high performance, high reliability, or something in
between. You specify the mapping you require in the JMS connection
factory settings. For example, see Default messaging provider unified connection factory [Settings].
Important:
If you
map the persistent JMS delivery mode to one of the service integration
nonpersistent levels (best effort nonpersistent, express
nonpersistent or reliable nonpersistent),
you risk losing messages in certain circumstances. For example, you
risk losing messages at server restart, or when there is heavy workload.
You specify default and maximum service integration reliability
levels as attributes of bus destinations (including foreign destinations
and alias destinations). You also specify whether the producer-specified
reliability overrides the default reliability for the destination:
if not, service integration resets the reliability level of the messages
to the default reliability for the destination. For alias destinations,
you can specify that the reliability setting is inherited from the
target destination.
For interoperation with
WebSphere MQ,
you map the reliability settings for service integration messages
to the persistence settings for
WebSphere MQ messages.
For more information, see Mapping the JMS delivery option and message reliability to and from the WebSphere MQ persistence value.
To help you choose the required reliability level, the following
table illustrates the behavior associated with the five levels of
reliability.
Note: In addition to setting the selected
reliability level, for messages to remain available after the various
failures shown in the table with certain reliability, the application
must be transactional.
Table 1. Behavior
of the five levels of reliability. The five columns in
the table lists the five message reliability levels and the corresponding
behavior associated with each of the five levels of reliability.
|
Best effort nonpersistent
|
Express nonpersistent
|
Reliable nonpersistent
|
Reliable persistent
|
Assured persistent
|
JMS delivery mode:
|
Nonpersistent
|
Nonpersistent
|
Nonpersistent
|
Persistent
|
Persistent
|
Transactionally atomic:
|
No, individual messages can be discarded |
Yes: messages are not discarded and never retained
beyond server restart |
Yes: messages are not discarded and never retained
beyond server restart |
Yes |
Yes |
Messages hardened:
|
No |
Possibly: when messages build up on a destination |
Possibly: when messages build up on a destination |
Yes: asynchronously |
Yes: synchronously |
Messages discarded in normal operation:
|
Yes |
No |
No |
No |
No |
Messages duplicated:
|
No |
Possibly: state data can be lost on server failure
resulting in duplication |
Possibly: state data can be lost on server failure
resulting in duplication |
Possibly: as deletion from the database is asynchronous
with respect to user requests |
No |
Messages are retained beyond planned shutdown:
|
No |
No |
No |
Yes: hardened messages are recovered, planned
shutdown hardens cached messages |
Yes |
Messages are retained beyond client comms
failure:
|
No |
No |
Yes |
Yes |
Yes |
Messages are retained beyond engine comms
failure:
|
No |
Yes |
Yes |
Yes |
Yes |
Messages are retained beyond engine crash:
|
No |
No |
No |
Possibly: hardened messages are recovered |
Yes |
Messages are retained beyond backup and restore:
|
No |
No |
No |
Possibly: hardened messages can be backed up
and recovered |
Yes |
The following provides an explanation of
the row 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.
- Messages 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, whereas 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 be 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 might choose to write messages
to disk in order to manage memory usage.
When a message whose
quality of service attribute is better than best effort nonpersistent is
written to disk, it might also be cached in a memory buffer.
- Messages discarded in normal operation
- Whether messages are discarded during normal operation.
-
Note:
If you have a non-transactional message-driven
bean, the system either deletes the message when the bean starts,
or when the bean completes. If the bean generates an exception, and
therefore does not complete, the system takes one of the following
actions:
- If the system is configured to delete the message when the bean
completes, then the message is despatched to a new instance of the
bean, so the message has another opportunity to be processed.
- If the system is configured to delete the message when the bean
starts, then the message is lost.
The message is deleted when the bean starts if
the quality of service is set to Best effort nonpersistent.
For all other qualities of service, the message is deleted when the
bean completes.
- Messages duplicated
- Whether messages are duplicated following a server failure.
- Messages are retained beyond planned shutdown
- Whether messages are retained beyond a planned shutdown or startup.
- Messages are retained beyond client comms failure
- Whether messages are retained beyond the failure of client-messaging
engine communication.
- Messages are retained beyond engine comms failure
- Whether messages are retained beyond the failure of inter-engine
communication.
- Messages are retained beyond engine crash
- Whether messages are retained beyond the failure of a messaging
engine or a server.
- Messages are retained beyond backup and restore
- Whether messages are retained beyond an online backup and restore
process.