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

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

全域性事務

全域性事務允許您使用多個事務性資源，通常是關係資料庫和訊息佇列。應用程式伺服器透過 JTA 管理全域性事務，JTA 是一個笨拙的 API（部分原因是其異常模型）。此外，JTA UserTransaction 通常需要從 JNDI 獲取，這意味著您還需要使用 JNDI 才能使用 JTA。全域性事務的使用限制了應用程式程式碼的任何潛在重用，因為 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 定義（而不是您的程式碼）。