JBoss EAP 05：MDB、RAR 與 IBM MQ，訊息進來之後誰負責提交？

HTTP 請求有呼叫端等回應，MDB 則由容器接收訊息後觸發。假設訂單訊息進來、資料庫更新後發生例外，下一步可能是回滾與重送。要解釋結果，得先知道訊息傳遞與交易由誰管理，不能只盯著 onMessage 裡面的幾行程式。

畫出一條完整訊息路徑

IBM MQ queue manager / queue
  → IBM MQ Jakarta resource adapter (RAR)
    → EAP EJB container → MDB.onMessage
      → business service → database

Transaction participation must be verified for each resource.

MDB 是 EJB 容器管理的元件，Spring @Service 是 Spring 管理的 Bean；名稱都叫注入，不代表兩套生命週期會自動互通。MDB 呼叫服務時，要找出那個物件如何建立，以及交易是否跨過這個邊界。把 MDB 換成 @JmsListener 會改變容器、連線與交易配置，應列成另一個設計決策。

Client jar、RAR、queue manager 是不同版本欄位

client jar 提供應用呼叫 MQ API 的類別；resource adapter 負責和應用伺服器整合。IBM MQ 文件分開提供 wmq.jmsra.rar 與 wmq.jakarta.jmsra.rar，對應不同 API 命名空間。這次 EAP 8.1／Jakarta 路徑要核對 Jakarta adapter；你列出的 client 9.4.5.1，還不足以推論 RAR 與遠端 queue manager 的版本或支援狀態。

工作表另外記錄 adapter archive、connection factory、destination JNDI、實體 queue、selector、並行數與交易模式。各 adapter 的 activation properties 不一定相同；EAP 內建 messaging broker 的範例不能原封不動當 IBM MQ 設定。教學包只放 adapter 名稱宣告，沒有提供可以直接上線的 MQ 連線設定。

onMessage 結束，交易結果還要看容器

對使用 container-managed transaction 的 MDB message listener，Jakarta Enterprise Beans 規範允許的 transaction attribute 是 REQUIRED 或 NOT_SUPPORTED。這是在規範層說明選項；實際使用哪個、MQ 與 DB 是否加入同一交易，仍要讀你的 annotation、描述檔、資源與 runtime。

若把例外 catch 後只寫 log 就正常返回，而沒有依契約標記回滾，容器可能視為處理完成。反過來，回滾後的重送也可能讓相同業務事件再次進入程式。不要把「只會收到一次」當前提；重送上限、backout／錯誤佇列與復原行為要依 IBM MQ adapter、queue 與應用設定逐項確認。

練習：DB 寫完後故意失敗

答案不是固定「一定回滾」。先依你已確認的交易模型寫預期：同一個有效的 XA 交易與兩段獨立提交，失敗結果可能不同。去重也要依業務識別鍵與既有契約判斷，不能只看某次 MQ message ID。這個練習要留下可重現的失敗位置與四種證據，教材本身沒有執行企業 MQ 測試。