共用方式為


持續性客戶端失敗

在某些情況下, 消息佇列 可以將訊息移至目的地佇列。 例如,如果佇列訪問控制不允許將訊息從用戶端移至伺服器,則會將違規訊息移至用戶端寄不出的信件佇列。 發生這種情況時,COM+ 佇列元件服務可讓例外狀況類別與元件相關聯。 若要將例外狀況類別與元件產生關聯,請使用 元件服務管理工具之元件屬性頁面中的 [進階 ] 索引卷標。 您也可以使用 COM+ 管理員 istrative 函式的 ExceptionClass 類別目錄元件屬性,以程式設計方式建立例外狀況類別的關聯。

例外狀況類別定義為實 作 IPlaybackControl 之元件的 ProgID 或 CLSID。 佇列元件服務具有無效信件佇列監視器,可掃描 Xact 寄不出的信件佇列。 如果佇列上有訊息,死信佇列監視器會具現化與目標元件相關聯的例外狀況處理程式,並呼叫 IPlaybackControl::FinalClientRetry,指出用戶端發生無法復原的錯誤。

除了 IPlaybackControl 之外,例外狀況處理程式應該實作與處理例外狀況的伺服器元件相同的介面集。 呼叫 IPlaybackControl::FinalClientRetry,佇列元件運行時間會將失敗的訊息播放回例外狀況處理程式。 這可讓例外狀況處理程式為無法移至伺服器的訊息實作替代行為,例如,藉由產生補償交易。

如果例外狀況處理程式完成播放的所有方法呼叫,則會從 Xact 寄不出的信件佇列中移除訊息並關閉。 不過,如果例外狀況處理程式會藉由從其中一個方法呼叫傳回失敗狀態來中止訊息,則會將訊息傳回至 Xact 死信佇列。 下列事件序列顯示用戶端例外狀況的處理方式:

  1. 消息佇列無法將訊息傳遞至伺服器,並將訊息放入 Xact 寄不出的信件佇列。
  2. 寄不出的信件佇列接聽程式 (DLQL) 會在 Xact 寄不出的信件佇列上尋找訊息。
  3. DLQL 會從訊息擷取目標元件 CLSID,並檢查例外狀況類別。
  4. DLQL 會具現化例外狀況類別。
  5. IPlaybackControlDLQL 查詢例外狀況類別。
  6. DLQL 會在例外狀況類別中呼叫 IPlaybackControl::FinalClientRetry 方法。
  7. DLQL 會將來自訊息的所有屬性和方法呼叫播放回例外狀況類別。
  8. 如果例外狀況處理程式成功完成交易,DLQL 就會刪除訊息。 例外狀況處理程式可能會發出 IObjectContext::SetAbort,而且訊息會保留在寄不出的信件佇列上。

如果上述任何步驟失敗,訊息會留在 Xact 寄不出的信件佇列上。

啟動時,DLQL 會在消息佇列交易死信佇列上讀取每個訊息,並具現化每個佇列元件訊息的例外狀況類別。 一次通過佇列之後,它會等候新的訊息。 然後,它會在送達時處理每個新的寄不出的信件佇列訊息。

如果您需要介入此處所述的程式,或如果您需要將有害訊息從其最終的待用佇列中移出,請使用訊息行動器公用程式。 如需訊息行動器公用程式的詳細資訊,請參閱 處理錯誤

用戶端錯誤

伺服器端錯誤