核心概念回顧
在 X/Open DTP 模型中，事務管理器 (TM) 協調全域事務的兩階段提交，資源管理器 (RM)（如 DB2、MQ）管理共享資源，應用程式 (AP) 定義事務邊界。當 RM 故障時，TM 能否維持運作、隔離影響範圍，直接決定系統可用性。
資源管理器故障的兩大災難性 XA 錯誤代碼
| 錯誤代碼 | 含義 | 典型成因 |
|---|
| XAER_RMERR | 事務分支中 RM 發生錯誤 | RM 拒絕提交分支、無法支援準備狀態、控制執行緒分離失敗 |
| XAER_RMFAIL | RM 發生一般性錯誤導致不可用 | RM 進程崩潰、儲存故障、網路中斷 |
四大關鍵故障場景與 TM 期望行為
場景 1：建立連接階段 (XA_OPEN) 發生錯誤
- 期望： TM 記錄警告並持續運行，拒絕導向該 RM 的新事務，不發送任何 XA 請求給不可用的 RM。
場景 2：事務啟動前 (XA_START/END/PREPARE) 偵測到錯誤
- 期望： 該事務標記失敗，不發送後續 XA 流給故障 RM，其他無關事務正常處理。
場景 3：準備/提交階段 RM 故障
- 期望： 事務狀態變為「無法確定」。RM 恢復後，TM 應能自動或透過重試完成提交/回滾；執行緒是否阻塞等待由實作決定。
場景 4：RM 長期不可用期間的系統整體可用性
- 核心指標： 非涉及故障 RM 的事務能否正常提交？TM 是否仍可處理非 XA 事務？故障 RM 恢復後，殘留事務是否自動解決？
四大彈性測試案例驗證 TM 高可用性
假設環境：多進程 TM，DB2 作為 RM，可人為控制 DB2 狀態（啟用/關閉）。
案例 1：事務執行中 RM 故障
- 步驟： TM 運行 → PoE 執行 DB2 事務 → 關閉 DB2 → 事務提交遭遇 XAER_RMERR → PoE 處理錯誤（如重啟）。
- 驗證點： 僅受影響 PoE 失敗，TM 整體可用；非 DB2 事務正常；DB2 恢復後重試事務成功。
案例 2：連接建立後 RM 故障
- 步驟： PoE 連接 DB2 → 關閉 DB2 → 執行非 DB2 事務（成功）→ 執行含 DB2 事務（失敗）→ 啟用 DB2 → 新事務正常。
- 驗證點： TM 可用性不受影響，故障隔離正確。
案例 3：RM 故障恢復後的舊連接殘留問題
- 步驟： PoE 連接 DB2 → 關閉 DB2 → 啟用 DB2 → 提交含 DB2 事務 → 檢查是否因舊連接句柄導致錯誤。
- 驗證點： TM 應清除失效連接，或重啟 PoE 重建連接，確保首次重試成功。
案例 4：RM 不可用時啟動新 PoE 並提交事務
- 步驟： DB2 離線 → 啟動新 PoE (XA_OPEN 失敗) → 提交含 DB2 SQL 事務 (SQL 錯誤) → 啟用 DB2 → 新事務成功。
- 驗證點： 非 DB2 事務完全不受影響，TM 核心服務持續線上。
TM 設計原則：防禦性架構清單
- 將故障 RM 標記為離線，核心引擎繼續服務其他 RM。
- 支援非故障 RM 事務的正常提交與回滾。
- 災難性錯誤不導致 TM 整體掛掉。
- 具備 RM 存活偵測機制（心跳/重試）。
- RM 恢復時自動解決懸而未決事務（In-doubt transactions）。
- RM 恢復後新事務請求即時可用，無殘留錯誤狀態。
- 連接池機制需在 RM 故障時主動淘汰失效連接，避免恢復後首次調用失敗。
實務補充：不同 RM 的錯誤代碼差異
- WebSphere MQ： 僅在帶同步點的
MQPUT 時才 ax_reg，若錯誤發生在該呼叫前，動態註冊模式下可能無法觸發 XA 彈性機制。
- 非 DB2 RM：
xa_end 失敗可能回傳 XAERR_PROTO 而非 XAERR_RMERR，TM 需容忍異質錯誤代碼。
結語
核心系統若將可用性視為第一優先級，TM 必須在 RM 故障時展現「彈性而非脆性」。上述測試案例可作為驗收標準，助您在上線前發現 TM 架構盲點，確保關鍵業務在局部故障下依然穩健運作。
