分散式交易處理疑問：UserTransaction 如何關聯多個 Session Bean？

程式碼情境

try {
    InitialContext initial = new InitialContext();
    UserTransaction ut = (UserTransaction) initial.lookup("java:comp/UserTransaction");
    SessionAHome aHome = (SessionAHome) initial.lookup("SessionA");
    SessionA a = aHome.create();
    SessionBHome bHome = (SessionBHome) initial.lookup("SessionB");
    SessionB b = bHome.create();

    ut.begin();
    a.fa();
    b.fb();
    ut.commit();
} catch (...) { ut.rollback(); }

核心疑問

ut 與 a、b 之間程式碼上無明顯關聯，JTS 如何知道：

1. ut.begin() 時，將交易上下文傳播到 a.fa() 與 b.fb() 操作的資源管理器？
2. ut.commit() 時，對這兩個資源管理器進行兩階段提交？

解析：容器與執行緒的隱性關聯

1. 執行緒綁定交易上下文：ut.begin() 會將交易上下文綁定到當前執行緒（ThreadLocal 機制）。
2. 遠端呼叫自動傳播：當呼叫 a.fa()、b.fb() 時，Stub/Skeleton 機制自動將當前執行緒的交易上下文透過 RMI-IIOP 傳遞給伺服器端。
3. 伺服器端關聯資源：伺服器端容器接收到交易上下文，將該交易關聯到該 Bean 操作的資源（如資料庫連線、JMS Session）。
4. 兩階段提交：ut.commit() 觸發交易管理器協調所有參與資源管理器進行 Prepare/Commit。

關鍵機制

• EJB 容器攔截器：容器在方法進入/退出時自動處理交易上下文綁定與解除
• 資源管理器註冊：資料庫連線（XADataSource）在取得時自動向交易管理器登記
• 執行緒區域性：交易上下文隨執行緒流動，不隨物件引用流動

結論

「澳妙」在於 JTS/OTS 規範定義的執行緒綁定傳播機制，以及容器與 Stub/Skeleton 的自動協作。開發者只需取得 UserTransaction 並 demarcation，容器負責其餘所有關聯與協調工作。