每一個非交易式的階段作業都會有一個確認模式, 以決定如何確認應用程式所接收到訊息。可能的確認模式有三種, 而所選的確認模式會影響應用程式的設計。
只有在應用程式連接 WebSphere MQ 佇列管理程式或 WebSphere 服務整合匯流排時, 這個主題中的資訊才適用。本資訊不適用於和分配管理系統間的即時連線。
XMS 所用的確認訊息接收機制和 JMS 相同。
如果階段作業不是交易式,則應用程式所收訊息的確認方式, 由階段作業的確認模式決定。確認模式有下列三種:
如果訊息是以同步方式傳遞給應用程式, 每當「接收」呼叫順利完成,階段作業即會確認收到訊息。如果訊息是以非同步方式傳遞給 C 應用程式, 每當訊息接聽器函數的呼叫順利完成,階段作業即會確認收到訊息。若為 C++ 應用程式, 每當訊息接聽器之 onMessage() 方法的呼叫順利完成, 階段作業即會確認收到訊息。
如果應用程式順利收到訊息, 但因某項失敗而無法進行確認,則訊息即可供重新遞送。因此, 應用程式必須能夠處理要重新遞送的訊息。
使用這種確認模式可減輕階段作業必須執行的工作量, 但如果發生失敗導致確認無法進行,可能意味著會有多則訊息將可供重新遞送。因此, 應用程式必須能夠處理任何要重新遞送的訊息。
應用程式可分別確認每一則訊息的接收。或者, 應用程式可接收訊息批次, 並只針對它所收到的最後一則訊息呼叫「確認」方法。呼叫「確認」方法時, 會確認自前次呼叫該方法以來所收到的所有訊息。
應用程式可在搭配使用任何這些確認模式的使用下, 呼叫 Session 類別的「回復」方法, 即可停止並重新啟動階段作業中的訊息遞送。凡是已收到但之前未經過確認的訊息將會重新遞送。不過, 這些訊息不見得會以先前的遞送順序來遞送。在這段期間, 較高優先順序的訊息可能已送達,而某些原始訊息可能已過期。此外在點對點網域中, 某些原始訊息可能已被另一個應用程式使用。
應用程式可藉由檢查訊息的 JMSRedelivered 標頭欄位內容, 來判斷訊息是否正在重新遞送。若要如此做,應用程式可呼叫 Message 類別的「取得 JMSRedelivered」方法。