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

Spring 框架的事务支持模型的优点

传统上,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