|
对于最新的稳定版本，请使用 Spring Framework 7.0.6! |
Spring框架事务支持模型的优势
传统上，企业级应用开发者在事务管理方面有两种选择： 全局事务或本地事务，这两种模式都存在显著的局限性。 接下来的两个章节将分别回顾全局事务管理和本地事务管理，随后讨论 Spring框架的事务管理支持如何解决全局事务模型和本地事务模型的局限性。
全局事务
全局事务允许您使用多个事务性资源，通常是关系型数据库和消息队列。应用服务器通过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。