传统上，EE 应用程序开发人员在事务管理方面有两种选择： 全局或本地事务，两者都有深刻的局限性。全球 接下来的两节将回顾本地事务管理，然后是 讨论 Spring 框架的事务管理支持如何解决 全局和本地事务模型的局限性。

全球交易

全局事务允许您使用多个事务资源，通常 关系数据库和消息队列。应用程序服务器管理全局 通过 JTA 进行交易，这是一个繁琐的 API（部分原因是其 异常模型）。此外，JTA 通常需要来自 JNDI，这意味着您还需要使用 JNDI 才能使用 JTA。用途 的全局事务限制了应用程序代码的任何潜在重用，因为 JTA 是 通常仅在应用程序服务器环境中可用。UserTransaction

以前，使用全局事务的首选方法是通过 EJB CMT （容器托管事务）。CMT 是声明性事务的一种形式 管理（与程序化事务管理不同）。EJB CMT 消除了与事务相关的 JNDI 查找的需要，尽管使用 EJB 本身需要使用 JNDI。它消除了大部分但不是全部的写入需求 用于控制事务的 Java 代码。显着的缺点是 CMT 与 JTA 相关联 以及应用程序服务器环境。此外，只有在人们选择的情况下，它才可用 在 EJB 中实现业务逻辑（或至少在事务性 EJB 外观后面）。这 一般来说，EJB 的负面影响是如此之大，以至于这不是一个有吸引力的提议， 特别是面对令人信服的声明性事务管理替代方案。

本地交易

本地事务是特定于资源的，例如与 JDBC 关联的事务 连接。本地事务可能更易于使用，但有一个明显的缺点： 它们不能跨多个事务资源工作。例如，管理 使用 JDBC 连接的事务不能在全局 JTA 事务中运行。因为 应用服务器不参与事务管理，它无法帮助确保 跨多个资源的正确性。（值得注意的是，大多数应用程序都使用 单个事务资源。另一个缺点是本地交易具有侵入性 到编程模型。

Spring Framework 的一致编程模型

Spring 解决了全局和本地事务的缺点。它让 应用程序开发人员在任何环境中都使用一致的编程模型。 您只需编写一次代码，就可以从不同的事务管理中受益 不同环境中的策略。Spring 框架提供声明式和 程序化事务管理。大多数用户更喜欢声明式事务 管理，我们在大多数情况下都推荐。

通过编程事务管理，开发人员可以使用 Spring 框架 事务抽象，可以在任何底层事务基础设施上运行。 使用首选的声明式模型时，开发人员通常很少或根本不编写代码 与事务管理相关，因此不依赖于 Spring 框架 事务 API 或任何其他事务 API。

您是否需要应用程序服务器进行事务管理？

Spring Framework 的事务管理支持改变了传统规则 当企业 Java 应用程序需要应用程序服务器时。

具体而言，您不需要纯粹用于声明性事务的应用程序服务器 通过 EJB。事实上，即使您的应用程序服务器具有强大的 JTA 功能， 你可能会认为 Spring 框架的声明式事务提供了更多的功能和 比 EJB CMT 更高效的编程模型。

通常，仅当应用程序需要时，才需要应用程序服务器的 JTA 功能 处理跨多个资源的事务，这对许多人来说不是必需的 应用。许多高端应用程序使用单个高度可伸缩的数据库（例如 Oracle RAC） 代替。独立事务管理器（如 Atomikos Transactions） 是其他选择。当然，您可能需要其他应用程序服务器功能，例如 Java 消息服务 （JMS） 和 Jakarta EE 连接器体系结构 （JCA）。

Spring Framework 使您可以选择何时将应用程序扩展到完全 加载的应用程序服务器。使用 EJB 的唯一替代方案的日子已经一去不复返了 CMT 或 JTA 是使用本地事务（例如 JDBC 连接上的事务）编写代码 如果您需要该代码在全局容器管理中运行，则将面临大量的返工 交易。在 Spring 框架中，只有 配置文件需要更改（而不是您的代码）。