Message reliability levels - JMS delivery mode and service integration quality of service

Messages have a quality of service attribute that we 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.

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 )

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

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 we 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. We 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 we 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, we 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.

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.

of the five levels of reliability. The five columns in the table lists the five message reliability levels and the corresponding

	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.

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

Related concepts

Point-to-point messaging with a WebSphere MQ network

Relative advantages of a file store and a data store

Service integration backup

Transaction support in WebSphere Application Server

Mapping the JMS delivery option and message reliability to and from the WebSphere MQ persistence value