传统上，Java EE开发人员在事务管理中有两种选择：全局或本地事务，这两者都有很大的局限性。下两节将回顾全局和本地事务管理，然后讨论Spring框架的事务管理支持如何解决全局和本地事务模型的局限性。

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

以前，使用全局事务的首选方法是通过EJB CMT（容器管理的事务）。CMT是声明式事务管理的一种形式（与编程式事务管理不同）。尽管使用EJB本身必须使用JNDI，但是EJB CMT消除了与事务相关的JNDI查找的需要。它消除了大多数（但不是全部）编写Java代码来控制事务的需求。重大缺点是CMT与JTA和应用程序服务器环境相关联。而且，仅当选择在EJB中（或至少在事务性EJB幕后）实现业务逻辑时，此功能才可用。EJB的缺点是如此之大，以至于这不是一个有吸引力的提议，特别是在面对声明性事务管理的引人注目的替代方案时。

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

Spring解决了全局事物和本地事物的缺陷。它使应用程序开发人员可以在任何环境中使用一致的编程模型。你只需编写一次代码，即可从不同环境中的不同事务管理策略中受益。Spring框架提供了声明式和编程式事务管理。大多数用户喜欢声明式事务管理，在大多数情况下我们建议这样做。

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

​ 你是否需要一个应用程序服务器来进行事务管理

Spring框架的事务管理支持更改了有关企业Java应用程序何时需要应用服务器的传统规则。

特别是，你不需要纯粹用于通过EJB进行声明式事务的应用程序服务器。实际上，即使你的应用服务器具有强大的JTA功能，你也可能会决定，与EJB CMT相比，Spring框架的声明式事务提供更多的功能和更高效的编程模型。

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

Spring框架使你可以选择何时将应用程序扩展到完全加载的应用程序服务器。不再使用EJB CMT或JTA的唯一选择是使用本地事务（例如JDBC连接上的事务）编写代码，并且如果你需要将该代码在全局的、容器管理的事务中运行，则面临大量的工作。使用Spring框架，仅需要更改配置文件中的某些Bean定义（而不是代码）。

个人从事金融行业，就职过易极付、思建科技、某网约车平台等重庆一流技术团队，目前就职于某银行负责统一支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。同时也热衷于技术分享创立公众号和博客站点对知识体系进行分享。关注公众号：青年IT男 获取最新技术文章推送！

博客地址： http://youngitman.tech

CSDN： https://blog.csdn.net/liyong1028826685

微信公众号：

技术交流群：