|
此版本仍在开发中，尚不被认为是稳定的。对于最新的稳定版本，请使用 Spring Framework 6.2.10！ |
Spring 框架事务支持模型的优势
传统上，EE 应用程序开发人员有两种事务管理选择： 全局或本地交易，两者都有深刻的局限性。全球 在接下来的两节中回顾了本地事务管理，然后是 讨论 Spring Framework 的事务管理支持如何解决 全球和本地交易模式的局限性。
全球交易
全局事务允许您使用多个事务资源，通常
关系数据库和消息队列。应用程序服务器管理全局
交易，这是一个繁琐的 API（部分原因是其
异常模型）。此外，JTAUserTransaction通常需要来源于
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 Framework 事务抽象，可以在任何底层事务基础设施上运行。 使用首选的声明式模型，开发人员通常很少或不编写代码 与事务管理相关，因此不依赖于 Spring Framework transaction API 或任何其他事务 API。