此版本仍在开发中，尚未被视为稳定版本。最新的稳定版本请使用 Spring Framework 6.1.13！spring-doc.cn

此版本仍在开发中，尚未被视为稳定版本。最新的稳定版本请使用 Spring Framework 6.1.13！spring-doc.cn

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

全球交易

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

以前，使用全局事务的首选方式是通过 EJB CMT （容器管理事务）。CMT 是一种声明式交易 管理（与编程事务管理不同）。EJB CMT 消除了与事务相关的 JNDI 查找的需要，尽管使用 EJB 本身就需要使用 JNDI。它消除了大部分但不是全部的编写需求 用于控制事务的 Java 代码。显着的缺点是 CMT 与 JTA 挂钩 以及应用程序服务器环境。此外，它仅在选择时可用 在 EJB 中实现业务逻辑（或至少在事务性 EJB 门面后面）。这 一般来说，EJB 的缺点是如此之大，以至于这不是一个有吸引力的提议。 尤其是在面对声明式事务管理的令人信服的替代方案时。spring-doc.cn

本地事务

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

Spring 框架的一致性编程模型

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

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

您需要一个用于事务管理的应用程序服务器吗？

Spring 框架的事务 Management 支持改变了传统的规则 当企业 Java 应用程序需要应用程序服务器时。spring-doc.cn

特别是，您不需要仅用于声明性事务的应用程序服务器 通过 EJB 进行。事实上，即使您的应用程序服务器具有强大的 JTA 功能， 你可以决定 Spring 框架的声明性事务提供了更多的功能，并且 比 EJB CMT 更高效的编程模型。spring-doc.cn

通常，仅当应用程序需要时，才需要应用程序服务器的 JTA 功能 处理跨多个资源的事务，这并不是许多人的要求 应用。许多高端应用程序使用单个高度可扩展的数据库（例如 Oracle RAC） 的 RAC）。独立事务管理器（例如 Atomikos 事务） 是其他选项。当然，您可能需要其他应用程序服务器功能，例如 Java 消息服务 （JMS） 和 Jakarta EE 连接器架构 （JCA）。spring-doc.cn

Spring Framework 允许您选择何时将应用程序扩展到完全 加载的应用程序服务器。使用 EJB 的唯一选择的日子已经一去不复返了 CMT 或 JTA 使用本地事务（例如 JDBC 连接上的事务）编写代码 如果您需要该代码在全局容器管理的 交易。使用 Spring 框架，只有 配置文件需要更改（而不是您的代码）。spring-doc.cn