JBoss EAP 04：JNDI、DataSource 與交易，連得上資料庫還不夠

應用說找不到 OrdersDS，管理員卻看得到同名 pool。兩邊可能談的是不同名稱：管理模型用 pool name 定位資源，應用常用 JNDI name 查找 DataSource。先把這條對應寫清楚，再追連線與交易。

從名字追到連線池

Application lookup: java:/jdbc/OrdersDS
  → EAP data-source resource: OrdersDS
    → driver reference
      → connection pool → database

Names are illustrative, not target-system configuration.

DataSource 提供取得連線的介面；pool 管理連線生命週期。JNDI 是查找命名資源的入口，不是資料庫本身。driver reference 也不是可靠的 JDBC jar 版本證據，要另外核對實際 driver artifact、版本與供應商支援。Java 21 中 DataSource 仍是 javax.sql.DataSource，不要改成 jakarta.sql。

讓 Boot 使用既有 JNDI 資源

# Illustrative application configuration for an EAP-hosted WAR.
spring.datasource.jndi-name=java:/jdbc/OrdersDS

這個設定表達使用已存在的 JNDI DataSource；實際是否生效還要看自訂 Bean、自動設定條件與部署環境。它不會替你建立 EAP 資源，也不證明交易管理器已接對。若同時保留自行建立 Hikari pool 的程式，要追實際注入的是哪個 Bean，不能只看 properties 判斷。

# Authorized standalone CLI; replace with a name discovered in the model.
/subsystem=datasources/data-source=OrdersDS:read-attribute(name=jndi-name)

read-attribute 觀察指定屬性。另一個常見操作 test-connection-in-pool 會真的取得／測試資料庫連線，因此沒有放入教材的唯讀觀察清單。即使它成功，也尚未驗證業務 SQL、schema、權限、隔離等級或失敗時的回滾；只能當作縮小問題範圍的一項證據。

JTA 與 XA 各自回答什麼

JTA 提供交易協調的 API 與管理方式；XA 是資源參與分散式交易的協定。宣告 XA DataSource 不等於 DB 與 MQ 已在同一筆交易裡：還要有正確交易管理器、adapter 能力、資源 enlistment、復原設定與實際執行路徑。Spring 的 @Transactional 也要查選中的管理器與代理是否真的生效。

先問業務要求什麼：新增訂單與送出訊息必須原子完成嗎？若是，就測提交、回滾與故障復原；若現有系統採 outbox 或補償流程，要驗證那套既有契約。升級工作不宜順手換交易模型，否則發現差異時很難知道是升級還是設計改動造成。

練習：AuditXA 的 enabled 沒有寫

離線工具對 AuditXA 回傳 enabled_declared: null。答案是「檔案沒有宣告」，不能把 null 改成 false，也不能宣稱 pool 可用。接著設計一個案例：DB 寫入後、MQ 完成前發生失敗，依舊系統契約列出 DB 應留下什麼、MQ 是否重送，以及哪個 log 能關聯它們。預期結果先填好，實際結果等訓練環境驗證後再填。