Spring事务管理
传统事务管理
传统上，J2EE开发者有两个事务管理的选择：全局事务和本地事务。全局事务由应用服务器管理，使用JTA。局部事务是和资源相关的，比如一个和JDBC连接关联的事务。这个选择有深刻的含义。例如，全局事务可以用于多个事务性的资源（典型例子是关系数据库和消息队列）。使用局部事务，应用服务器不需要参与事务管理，但是不能确保跨越多个资源（需要指出的是多数应用使用单一事务性的资源）的事务的正确性。
- 全局事务
全局事务有一个重大的缺陷，代码需要使用JTA：一个笨重的API（部分是因为它的异常模型）。此外，JTA的UserTransaction通常需要从JNDI获得，这意味着我们为了JTA，需要同时使用JNDI好JTA。显然全部使用全局事务限制了应用代码的重用性，因为JTA通常只在应用服务器的环境中才能使用。以前使用全局事务的首选方式是通过EJB的CMT（容器管理事务）：CMT是声明式事务管理的一种形式（区别于编程式事务管理）。EJB的CMT不需要任何核事务相关的JNDI查找，虽然使用EJB本身肯定需要使用JNDI。它消除了大多数硬编码的方式去控制事务。重大的缺陷是CMT绑定在JTA和应用服务器环境上，并且只有我们选择使用EJB实现业务逻辑，或者至少处于一个事务化EJB的Facade后才能使用它。EJB有如此多的诟病，尤其是存在其它声明式事务管理时，EJB不是一个吸引人的建议。
- 本地事物
本地事务容易使用，但是也有明显的缺点：它们不能用于多个事务性资源。例如，使用JDBC连接事务管理的代码不能用于全局的JTA事务中。另一个缺点是局部事务趋向于侵入式的编程模型。
Spring事务管理
Spring使得应用开发者能够在任何环境下使用一致的编程模型。你可以只写一次你的代码，这在不同环境下的不同事务管理策略中有很多益处。Spring同时提供声明式和编程式事务管理。声明式事务管理是多数使用者的首选，在多数情况下是被推荐使用的。
Spring框架对事务管理的支持极大的改变了传统上认为J2EE应用需要应用服务器的认识。这种改变尤其在于你不需要仅仅为了通过EJB来使用声明式事务而使用应用服务器。事实上，即使你的应用服务器拥有强大的JTA功能，你也有充分的理由可以发现，Spring框架的声明式事务提供了比EJB的CMT更强大、高效的编程模型。
一般来说，只有当你需要支持多个事务性资源时，你才需要应用服务器的JTA功能。而大多数应用并不需要处理跨越多种资源。许多高端应用使用单一的、高伸缩性的数据库。当然，也许你需要应用服务器的其他功能，比如JMS或JCA。
最重要的一点是，使用Spring，你可以选择何时把你的应用迁移到全功能的应用服务器。用硬编码去实现本地事务来替代EJB CMT或JTA，处理JDBC连接，或者还需要使用硬编码来处理那些全局的、受到容器管理的事务，这样的日子将一去不复返了。使用Spring，只需要改动配置文件，而不必改动代码。