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.

Note: The term message reliability level corresponds to all of the following terms:
  • Quality of service (QoS) (service integration messaging)
  • Delivery mode (JMS)
  • Persistence (IBM MQ )
You can specify the following service integration message reliability levels for messages. The options are listed in order of increasing reliability.
最大努力非持續性
傳訊引擎停止或失效時捨棄的訊息。訊息也可能因為用來傳送訊息的連線無法使用,或系統資源受到限制,而遭到捨棄。
快速非持續性
傳訊引擎停止或失效時捨棄的訊息。如果用來傳送訊息的連線無法使用,也可能捨棄訊息。
可靠非持續性
傳訊引擎停止或失效時捨棄的訊息。
可靠持續性
當傳訊引擎失敗時,可能會捨棄訊息。
確定持續性
不捨棄訊息。
Note: 可靠性層次越高,效能影響越大。

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 [設定].

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 IBM MQ, you map the reliability settings for service integration messages to the persistence settings for IBM MQ messages. For more information, see Mapping the JMS delivery option and message reliability to and from the IBM 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:
如果您有非交易式訊息驅動 Bean,系統會在 Bean 啟動或完成時刪除訊息。如果 Bean 產生異常狀況,並因此而沒有完成,系統會採取下列其中一項動作:
  • 如果系統的配置是在 Bean 完成時刪除訊息,則訊息會分派給新的 Bean 實例,因此就有另一次機會可以處理訊息。
  • 如果系統的配置是在 Bean 啟動時刪除訊息,則訊息會遺失。

如果服務品質設為最大努力非持續性,訊息會在 Bean 啟動時刪除。如果是所有的其他服務品質,則會在 Bean 完成時刪除訊息。

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.

指出主題類型的圖示 概念主題



時間戳記圖示 前次更新: July 9, 2016 11:10
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjj9000_
檔名:cjj9000_.html