Message reliability levels - JMS delivery mode and service integration quality of service
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.
- Quality of service (QoS) (service integration messaging)
- Delivery mode (JMS)
- Persistence (IBM MQ )
- 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.
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.
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 IBM MQ, you map the reliability settings for service integration messages to the persistence settings for IBM MQ messages.
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 |
- 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.
- 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.