Spring 框架事務支援模型的優勢

傳統上，EE 應用開發人員有兩種事務管理選擇：全域性事務或區域性事務，兩者都有深刻的侷限性。接下來的兩節將回顧全域性事務和區域性事務管理，然後討論 Spring 框架的事務管理支援如何解決全域性和區域性事務模型的侷限性。

全域性事務

全域性事務允許您使用多個事務性資源，通常是關係資料庫和訊息佇列。應用伺服器透過 JTA 管理全域性事務，JTA 是一個繁瑣的 API（部分原因在於其異常模型）。此外，JTA `UserTransaction` 通常需要從 JNDI 獲取，這意味著要使用 JTA，您還需要使用 JNDI。全域性事務的使用限制了應用程式碼的任何潛在重用，因為 JTA 通常僅在應用伺服器環境中可用。

以前，使用全域性事務的首選方式是透過 EJB CMT（容器管理事務）。CMT 是一種宣告式事務管理形式（與程式設計式事務管理不同）。EJB CMT 消除了事務相關的 JNDI 查詢需求，儘管使用 EJB 本身也需要使用 JNDI。它消除了大部分但不是全部編寫 Java 程式碼來控制事務的需要。顯著的缺點是 CMT 繫結到 JTA 和應用伺服器環境。此外，只有當選擇在 EJB 中實現業務邏輯（或至少在事務性 EJB 外觀之後）時，它才可用。總的來說，EJB 的缺點非常大，因此這不是一個有吸引力的選擇，尤其是在宣告式事務管理存在引人注目的替代方案的情況下。

區域性事務

區域性事務是資源特定的，例如與 JDBC 連線關聯的事務。區域性事務可能更容易使用，但有一個顯著的缺點：它們不能跨越多個事務性資源工作。例如，使用 JDBC 連線管理事務的程式碼不能在全域性 JTA 事務中執行。由於應用伺服器不參與事務管理，它無法幫助確保跨多個資源的正確性。（值得注意的是，大多數應用程式使用單個事務資源。）另一個缺點是區域性事務對程式設計模型具有侵入性。

Spring 框架的一致程式設計模型

Spring 解決了全域性事務和區域性事務的缺點。它允許應用開發人員在任何環境中使用一致的程式設計模型。您只需編寫一次程式碼，它就可以從不同環境中的不同事務管理策略中獲益。Spring 框架提供了宣告式和程式設計式事務管理。大多數使用者更喜歡宣告式事務管理，我們在大多數情況下也推薦使用它。

使用程式設計式事務管理時，開發人員使用 Spring 框架事務抽象，該抽象可以在任何底層事務基礎設施之上執行。使用首選的宣告式模型時，開發人員通常編寫很少或不編寫與事務管理相關的程式碼，因此不依賴於 Spring 框架事務 API 或任何其他事務 API。

事務管理是否需要應用伺服器？

Spring 框架的事務管理支援改變了企業 Java 應用何時需要應用伺服器的傳統規則。

特別是，您不再僅僅為了透過 EJB 實現宣告式事務而需要應用伺服器。實際上，即使您的應用伺服器具有強大的 JTA 能力，您也可能決定 Spring 框架的宣告式事務比 EJB CMT 提供更多的功能和更高效的程式設計模型。

通常，只有當您的應用程式需要跨多個資源處理事務時，才需要應用伺服器的 JTA 能力，而這對於許多應用程式來說並不是必需的。許多高階應用會使用單個、高度可伸縮的資料庫（如 Oracle RAC）來代替。獨立的事務管理器（如 Atomikos Transactions）是其他選擇。當然，您可能需要應用伺服器的其他功能，例如 Java 訊息服務 (JMS) 和 Jakarta EE 聯結器架構 (JCA)。

Spring 框架讓您可以自由選擇何時將應用擴充套件到功能齊全的應用伺服器。那種除了使用 EJB CMT 或 JTA 之外，只能用區域性事務（例如基於 JDBC 連線的事務）編寫程式碼，並且在需要將這些程式碼執行在全域性、容器管理事務中時面臨大量返工的日子已經一去不復返了。使用 Spring 框架，只需更改配置檔案中的某些 bean 定義（而不是程式碼）。