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

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

全局事务

全局事务允许您使用多个事务资源，通常是关系数据库和消息队列。应用程序服务器通过JTA管理全局事务，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。

您是否需要应用程序服务器进行事务管理？

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

特别是，您不需要仅仅为了通过EJB进行声明式事务而使用应用程序服务器。实际上，即使您的应用程序服务器具有强大的JTA功能，您也可能决定Spring框架的声明式事务比EJB CMT提供更强大的功能和更具生产力的编程模型。

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

Spring框架让您选择何时将应用程序扩展到功能齐全的应用程序服务器。使用EJB CMT或JTA的唯一替代方案是编写使用本地事务（例如JDBC连接上的事务）的代码的日子已经一去不复返了，如果您需要该代码在全局容器管理的事务中运行，则需要进行大量重写。使用Spring框架，您配置文件中只需要更改一些Bean定义（而不是您的代码）。