Java 理論與實踐：理解 JTS —— 事務管理基礎與 ACID 特性

Java Transaction Service (JTS) 是 J2EE 架構的關鍵基石，配合 Java Transaction API (JTA) 構建對系統與網絡故障高度健壯的分布式應用。事務是可靠應用的基本構建塊——沒有事務支持，編寫可靠分布式應用極其困難。幸運的是，JTS 大部分工作對程序員透明；J2EE 容器使事務劃分與資源征用幾乎不可見。

事務的動機：為什麼需要事務？

考慮銀行轉賬：從賬戶 A 扣款、向賬戶 B 存款、記錄流水。若系統在寫入第一筆後崩潰，資金憑空消失或憑空產生。甚至無故障時，併發轉賬也可能導致負餘額。企業數據系統必須在火災、洪水、斷電、磁盤故障下保持正確記錄。事務提供框架，在組件故障時保持數據一致性與完整性。

什麼是事務？ACID 特性詳解

事務是對應用狀態的一組相關操作，具備四大特性：

• 原子性：要麼全做，要麼全不做；不可分割的工作單元
• 一致性：事務代表狀態的正確轉換，不違反完整性約束（如資產總和 = 負債總和）
• 隔離性：併發事務效果等同串行執行；通常通過鎖機制實現，有時為性能放寬隔離級別
• 持久性：提交後的更改「經得起失敗」；具體故障恢復能力取決於系統設計（冗余磁盤、異地數據中心等）

事務剖析：參與者與生命週期

• 應用程序：發起事務邏輯
• 事務監視器 (TPM)：協調資源管理器，確保「全有或全無」
• 資源管理器 (RM)：存儲狀態（數據庫、JMS 隊列等）

生命週期：應用請求啟動事務 → 訪問各 RM（自動征用） → 提交或回滾。提交則持久化並對新事務可見；回滾則丟棄所有更改，如事務從未發生。

事務日誌：持久性與性能的關鍵

RM 通過事務日誌（連續磁盤文件，主要寫入）獲得持久性與可接受性能：只寫入變更而非整塊數據，減少磁盤尋道；多事務變更可合併寫入。重啟時重放日誌中已提交事務，保證持久性並延遲磁盤 I/O 到低峰期。

兩階段提交 (2PC)：跨資源管理器的原子性

單 RM 由其內置事務管理器處理。多 RM（如兩數據庫、數據庫+JMS）需 TPM 協調 2PC：

1. 準備階段：TPM 向各 RM 發送「準備」，詢問能否提交
2. 提交階段：全體確認 → TPM 在自身日誌標記提交 → 指示所有 RM 提交；任一失敗 → 全部回滾

類比婚禮：雙方皆答「我願意」才宣告結婚；任一方拒絕或沉默，婚禮不成立。

事務作為異常處理機制

同步主要解決併發控制，事務主要解決異常處理。若無故障世界，不需要事務。事務如商業合同：一方違約則交易作廢。類比 Java try-catch-finally：事務將清理工作委託給 TPM/RM（ROLLBACK），簡化代碼，專注業務邏輯。

系列展望

第二部分：J2EE 如何將事務語義傳遞給 EJB/Servlet/JSP，資源征用透明化，事務跨組件/系統傳播。第三部分：事務劃分策略與資源使用最佳實踐——不正確劃分導致不一致狀態，不正確資源使用導致嚴重性能問題。