【转】 Spring 事务管理高级运用难点剖析 第1部分

【转】 Spring 事务管理高级应用难点剖析 第1部分

?

概述

Spring 最成功，最吸引人的地方莫过于轻量级的声明式事务管理，仅此一点，它就宣告了重量级 EJB 容器的覆灭。Spring 声明式事务管理将开发者从繁复的事务管理代码中解脱出来，专注于业务逻辑的开发上，这是一件可以被拿来顶礼膜拜的事情。但是，世界并未从此消停，开发人员需要面对的是层出不穷的应用场景，这些场景往往逾越了普通 Spring 技术书籍的理想界定。因此，随着应用开发的深入，在使用经过 Spring 层层封装的声明式事务时，开发人员越来越觉得自己坠入了迷雾，陷入了沼泽，体会不到外界所宣

DAO 和事务管理的牵绊

很少有使用 Spring 但不使用 Spring 事务管理器的应用，因此常常有人会问：是否用了 Spring，就一定要用 Spring 事务管理器，否则就无法进行数据的持久化操作呢？事务管理器和 DAO 是什么关系呢？

也许是 DAO 和事务管理如影随行的缘故吧，这个看似简单的问题实实在在地存在着，从初学者心中涌出，萦绕在开发老手的脑际。答案当然是否定的！我们都知道：事务管理是保证数据操作的事务性（即原子性、一致性、隔离性、持久性，也即所谓的 ACID），脱离了事务性，DAO 照样可以顺利地进行数据的操作。

下面，我们来看一段使用 Spring JDBC 进行数据访问的代码：

清单 1. UserJdbcWithoutTransManagerService.java

应用分层的迷惑
Web、Service 及 DAO 三层划分就像西方国家的立法、行政、司法三权分立一样被奉为金科玉律，甚至有开发人员认为如果要使用 Spring 的事务管理就一定先要进行三层的划分。这个看似荒唐的论调在开发人员中颇有市场。更有甚者，认为每层必须先定义一个接口，然后再定义一个实现类。其结果是：一个很简单的功能，也至少需要 3 个接口，3 个类，再加上视图层的 JSP 和 JS 等，打牌都可以转上两桌了，这种误解贻害不浅。
对将“面向接口编程”奉为圭臬，认为放之四海而皆准的论调，笔者深不以为然。是的，“面向接口编程”是 Martin Fowler，Rod Johnson 这些大师提倡的行事原则。如果拿这条原则去开发架构，开发产品，怎么强调都不为过。但是，对于我们一般的开发人员来说，做的最多的是普通工程项目，往往最多的只是一些对数据库增、删、查、改的功能。此时，“面向接口编程”除了带来更多的类文件外，看不到更多其它的好处。
Spring 框架提供的所有附加的好处（AOP、注解增强、注解 MVC 等）唯一的前提就是让 POJO 的类变成一个受 Spring 容器管理的 Bean，除此以外没有其它任何的要求。下面的实例用一个 POJO 完成所有的功能，既是 Controller，又是 Service，还是 DAO：

清单 5. MixLayerUserService.java

在 ① 处，我们定义配置了 AnnotationMethodHandlerAdapter，以便启用 Spring MVC 的注解驱动功能。而②和③处通过 Spring 的 aop 及 tx 命名空间，以及 Aspject 的切点表达式语法进行事务增强的定义，对 MixLayerUserService 的所有公有方法进行事务增强。要使程序能够运行起来还必须进行 web.xml 的相关配置：

清单 7.web.xml

这个配置文件很简单，唯一需要注意的是 DispatcherServlet 的配置。默认情况下 Spring MVC 根据 Servlet 的名字查找 WEB-INF 下的 <servletName>-servlet.xml 作为 Spring MVC 的配置文件，在此，我们通过 contextConfigLocation 参数显式指定 Spring MVC 配置文件的确切位置。
将 org.springframework.jdbc 及 org.springframework.transaction 的日志级别设置为 DEBUG，启动项目，并访问 http://localhost:8088/logon.do?userName=tom 应用，MixLayerUserService#logon 方法将作出响应，查看后台输出日志：

清单 8 执行日志
事务方法嵌套调用的迷茫
Spring 事务一个被讹传很广说法是：一个事务方法不应该调用另一个事务方法，否则将产生两个事务。结果造成开发人员在设计事务方法时束手束脚，生怕一不小心就踩到地雷。
其实这种是不认识 Spring 事务传播机制而造成的误解，Spring 对事务控制的支持统一在 TransactionDefinition 类中描述，该类有以下几个重要的接口方法：
int getPropagationBehavior()：事务的传播行为
int getIsolationLevel()：事务的隔离级别
int getTimeout()：事务的过期时间
boolean isReadOnly()：事务的读写特性。
很明显，除了事务的传播行为外，事务的其它特性 Spring 是借助底层资源的功能来完成的，Spring 无非只充当个代理的角色。但是事务的传播行为却是 Spring 凭借自身的框架提供的功能，是 Spring 提供给开发者最珍贵的礼物，讹传的说法玷污了 Spring 事务框架最美丽的光环。
所谓事务传播行为就是多个事务方法相互调用时，事务如何在这些方法间传播。Spring 支持 7 种事务传播行为：
PROPAGATION_REQUIRED 如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
PROPAGATION_SUPPORTS 支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY 使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW 新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER 以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与 PROPAGATION_REQUIRED 类似的操作。
Spring 默认的事务传播行为是 PROPAGATION_REQUIRED，它适合于绝大多数的情况。假设 ServiveX#methodX() 都工作在事务环境下（即都被 Spring 事务增强了），假设程序中存在如下的调用链：Service1#method1()->Service2#method2()->Service3#method3()，那么这 3 个服务类的 3 个方法通过 Spring 的事务传播机制都工作在同一个事务中。
下面，我们来看一下实例，UserService#logon() 方法内部调用了 UserService#updateLastLogonTime() 和 ScoreService#addScore() 方法，这两个类都继承于 BaseService。它们之间的类结构说明如下：

图 1. UserService 和 ScoreService
?
具体的代码如下所示：

清单 9 UserService.java

将日志级别设置为 DEBUG，启动 Spring 容器并执行 UserService#logon() 的方法，仔细观察如下的输出日志：

清单 12 执行日志
多线程的困惑
由于 Spring 的事务管理器是通过线程相关的 ThreadLocal 来保存数据访问基础设施，再结合 IOC 和 AOP 实现高级声明式事务的功能，所以 Spring 的事务天然地和线程有着千丝万缕的联系。
我们知道 Web 容器本身就是多线程的，Web 容器为一个 Http 请求创建一个独立的线程，所以由此请求所牵涉到的 Spring 容器中的 Bean 也是运行于多线程的环境下。在绝大多数情况下，Spring 的 Bean 都是单实例的（singleton），单实例 Bean 的最大的好处是线程无关性，不存在多线程并发访问的问题，也即是线程安全的。
一个类能够以单实例的方式运行的前提是“无状态”：即一个类不能拥有状态化的成员变量。我们知道，在传统的编程中，DAO 必须执有一个 Connection，而 Connection 即是状态化的对象。所以传统的 DAO 不能做成单实例的，每次要用时都必须 new 一个新的实例。传统的 Service 由于将有状态的 DAO 作为成员变量，所以传统的 Service 本身也是有状态的。
但是在 Spring 中，DAO 和 Service 都以单实例的方式存在。Spring 是通过 ThreadLocal 将有状态的变量（如 Connection 等）本地线程化，达到另一个层面上的“线程无关”，从而实现线程安全。Spring 不遗余力地将状态化的对象无状态化，就是要达到单实例化 Bean 的目的。
由于 Spring 已经通过 ThreadLocal 的设施将 Bean 无状态化，所以 Spring 中单实例 Bean 对线程安全问题拥有了一种天生的免疫能力。不但单实例的 Service 可以成功运行于多线程环境中，Service 本身还可以自由地启动独立线程以执行其它的 Service。下面，通过一个实例对此进行描述：

清单 13 UserService.java 在事务方法中启动独立线程运行另一个事务方法
小结
Spring 声明式事务是 Spring 最核心，最常用的功能。由于 Spring 通过 IOC 和 AOP 的功能非常透明地实现了声明式事务的功能，一般的开发者基本上无须了解 Spring 声明式事务的内部细节，仅需要懂得如何配置就可以了。
但是在实际应用开发过程中，Spring 的这种透明的高阶封装在带来便利的同时，也给我们带来了迷惑。就像通过流言传播的消息，最终听众已经不清楚事情的真相了，而这对于应用开发来说是很危险的。本系列文章通过剖析实际应用中给开发者造成迷惑的各种难点，通过分析 Spring 事务管理的内部运作机制将真相还原出来。
在本文中，我们通过剖析了解到以下的真相：
在没有事务管理的情况下，DAO 照样可以顺利进行数据操作；
将应用分成 Web，Service 及 DAO 层只是一种参考的开发模式，并非是事务管理工作的前提条件；
Spring 通过事务传播机制可以很好地应对事务方法嵌套调用的情况，开发者无须为了事务管理而刻意改变服务方法的设计；
由于单实例的对象不存在线程安全问题，所以进行事务管理增强的 Bean 可以很好地工作在多线程环境下。
在?下一篇?文章中，笔者将继续分析 Spring 事务管理的以下难点：
混合使用多种数据访问技术（如 Spring JDBC + Hibernate）的事务管理问题；
进行 Spring AOP 增强的 Bean 存在哪些特殊的情况。

参考资料
学习
查看?本系列?文章的?第 2 部分?和?第 3 部分。?

参考?Spring 2.5 技术参考手册，您可以了解更多需要强调的内容。?

“教程：全面分析 Spring 的编程式事务管理及声明式事务管理”（developerWorks，2009 年 1 月）：本教程从基础知识开始，详细分析了 Spring 事务管理的使用方法，为读者理清思路。

“Java 理论与实践: 理解 JTS —— 事务简介”（developerWorks，2007 年 2 月）：讲述了一些基础知识，包括什么是事务，以及事务对于构建可靠 的分布式应用程序来说至关重要的原因。

“事务策略: 了解事务陷阱”（developerWorks，2009 年 3 月）：该系列文章通过使用 Spring Framework 和企业 EJB 3.0 规范中的代码示例解释了这些极其常见的错误。

“Spring 系列: Spring 框架简介”（developerWorks，2005 年 8 月）：开始学习如何用 Spring 技术构建轻量级的、强壮的 J2EE 应用程序。

“使用 Spring 2.5 注释驱动的 IoC 功能”（developerWorks，2008 年 2 月）：本文通过实例详细讲述了 Spring 2.5 基于注释 IoC 功能的使用。

“使用 Spring 2.5 基于注解驱动的 Spring MVC”（developerWorks，2008 年 3 月）：本文将介绍 Spring 2.5 新增的 Sping MVC 注解功能，讲述如何使用注解配置替换传统的基于 XML 的 Spring MVC 配置。

技术书店：浏览关于这些和其他技术主题的图书。

developerWorks Java 技术专区：数百篇关于 Java 编程各个方面的文章。

? ?? 本文出自 http://www.ibm.com/developerworks/cn/java/j-lo-spring-ts1/index.html
?