9.1 数据库事务概述

9.1 数据库事务概述http://www.cnblogs.com/duanxz/p/3788190.html

事务首先是一系列操作组成的工作单元，该工作单元内的操作是不可分割的，即要么所有操作都做，要么所有操作都不做，这就是事务。

事务必需满足ACID（原子性、一致性、隔离性和持久性）特性，缺一不可：

原子性（Atomicity）：即事务是不可分割的最小工作单元，事务内的操作要么全做，要么全不做；
一致性（Consistency）：在事务执行前数据库的数据处于正确的状态，而事务执行完成后数据库的数据还是处于正确的状态，即数据完整性约束没有被破坏；如银行转帐，A转帐给B，必须保证A的钱一定转给B，一定不会出现A的钱转了但B没收到，否则数据库的数据就处于不一致（不正确）的状态。
隔离性（Isolation）：并发事务执行之间无影响，在一个事务内部的操作对其他事务是不产生影响，这需要事务隔离级别来指定隔离性；
持久性（Durability）：事务一旦执行成功，它对数据库的数据的改变必须是永久的，不会因比如遇到系统故障或断电造成数据不一致或丢失。

在实际项目开发中数据库操作一般都是并发执行的，即有多个事务并发执行，并发执行就可能遇到问题，目前常见的问题如下：

丢失更新：两个事务同时更新一行数据，最后一个事务的更新会覆盖掉第一个事务的更新，从而导致第一个事务更新的数据丢失，这是由于没有加锁造成的；
脏读：一个事务看到了另一个事务未提交的更新数据；
不可重复读：在同一事务中，多次读取同一数据却返回不同的结果；也就是有其他事务更改了这些数据；
幻读：一个事务在执行过程中读取到了另一个事务已提交的插入数据；即在第一个事务开始时读取到一批数据，但此后另一个事务又插入了新数据并提交，此时第一个事务又读取这批数据但发现多了一条，即好像发生幻觉一样。

为了解决这些并发问题，需要通过数据库隔离级别来解决，在标准SQL规范中定义了四种隔离级别：

未提交读（Read Uncommitted）：最低隔离级别，一个事务能读取到别的事务未提交的更新数据，很不安全，可能出现丢失更新、脏读、不可重复读、幻读；
提交读（Read Committed）：一个事务能读取到别的事务提交的更新数据，不能看到未提交的更新数据，不可能可能出现丢失更新、脏读，但可能出现不可重复读、幻读；
可重复读（Repeatable Read）：保证同一事务中先后执行的多次查询将返回同一结果，不受其他事务影响，可能可能出现丢失更新、脏读、不可重复读，但可能出现幻读；
序列化（Serializable）：最高隔离级别，不允许事务并发执行，而必须串行化执行，最安全，不可能出现更新、脏读、不可重复读、幻读。

隔离级别越高，数据库事务并发执行性能越差，能处理的操作越少。因此在实际项目开发中为了考虑并发性能一般使用提交读隔离级别，它能避免丢失更新和脏读，尽管不可重复读和幻读不能避免，但可以在可能出现的场合使用悲观锁或乐观锁来解决这些问题。

9.1.1 事务类型

数据库事务类型有本地事务和分布式事务：

本地事务：就是普通事务，能保证单台数据库上的操作的ACID，被限定在一台数据库上；
分布式事务：涉及两个或多个数据库源的事务，即跨越多台同类或异类数据库的事务（由每台数据库的本地事务组成的），分布式事务旨在保证这些本地事务的所有操作的ACID，使事务可以跨越多台数据库；

Java事务类型有JDBC事务和JTA事务：

JDBC事务：就是数据库事务类型中的本地事务，通过Connection对象的控制来管理事务；
JTA事务：JTA指Java事务API(Java Transaction API)，是Java EE数据库事务规范， JTA只提供了事务管理接口，由应用程序服务器厂商（如WebSphere Application Server）提供实现，JTA事务比JDBC更强大，支持分布式事务。

Java EE事务类型有本地事务和全局事务：

本地事务：使用JDBC编程实现事务；
全局事务：由应用程序服务器提供，使用JTA事务；

按是否通过编程实现事务有声明式事务和编程式事务；

声明式事务：通过注解或XML配置文件指定事务信息；
编程式事务：通过编写代码实现事务。

9.1.2 Spring提供的事务管理

Spring框架最核心功能之一就是事务管理，而且提供一致的事务管理抽象，这能帮助我们：

提供一致的编程式事务管理API，不管使用Spring JDBC框架还是集成第三方框架使用该API进行事务编程；
无侵入式的声明式事务支持。

Spring支持声明式事务和编程式事务事务类型。

9.2.1 概述

Spring框架支持事务管理的核心是事务管理器抽象，对于不同的数据访问框架（如Hibernate）通过实现策略接口PlatformTransactionManager，从而能支持各种数据访问框架的事务管理，PlatformTransactionManager接口定义如下：

java代码：

getTransaction()：返回一个已经激活的事务或创建一个新的事务（根据给定的TransactionDefinition类型参数定义的事务属性），返回的是TransactionStatus对象代表了当前事务的状态，其中该方法抛出TransactionException（未检查异常）表示事务由于某种原因失败。
commit()：用于提交TransactionStatus参数代表的事务，具体语义请参考Spring Javadoc；
rollback()：用于回滚TransactionStatus参数代表的事务，具体语义请参考Spring Javadoc。

TransactionDefinition接口定义如下：

java代码：

getPropagationBehavior()：返回定义的事务传播行为；
getIsolationLevel()：返回定义的事务隔离级别；
getTimeout()：返回定义的事务超时时间；
isReadOnly()：返回定义的事务是否是只读的；
getName()：返回定义的事务名字。

TransactionStatus接口定义如下：

java代码：

isNewTransaction()：返回当前事务状态是否是新事务；
hasSavepoint()：返回当前事务是否有保存点；
setRollbackOnly()：设置当前事务应该回滚；
isRollbackOnly(()：返回当前事务是否应该回滚；
flush()：用于刷新底层会话中的修改到数据库，一般用于刷新如Hibernate/JPA的会话，可能对如JDBC类型的事务无任何影响；
isCompleted():当前事务否已经完成。

9.2.2 内置事务管理器实现

Spring提供了许多内置事务管理器实现：

DataSourceTransactionManager：位于org.springframework.jdbc.datasource包中，数据源事务管理器，提供对单个javax.sql.DataSource事务管理，用于Spring JDBC抽象框架、iBATIS或MyBatis框架的事务管理；
JdoTransactionManager：位于org.springframework.orm.jdo包中，提供对单个javax.jdo.PersistenceManagerFactory事务管理，用于集成JDO框架时的事务管理；
JpaTransactionManager：位于org.springframework.orm.jpa包中，提供对单个javax.persistence.EntityManagerFactory事务支持，用于集成JPA实现框架时的事务管理；
HibernateTransactionManager：位于org.springframework.orm.hibernate3包中，提供对单个org.hibernate.SessionFactory事务支持，用于集成Hibernate框架时的事务管理；该事务管理器只支持Hibernate3+版本，且Spring3.0+版本只支持Hibernate 3.2+版本；
JtaTransactionManager：位于org.springframework.transaction.jta包中，提供对分布式事务管理的支持，并将事务管理委托给Java EE应用服务器事务管理器；
OC4JjtaTransactionManager：位于org.springframework.transaction.jta包中，Spring提供的对OC4J10.1.3+应用服务器事务管理器的适配器，此适配器用于对应用服务器提供的高级事务的支持；
WebSphereUowTransactionManager：位于org.springframework.transaction.jta包中，Spring提供的对WebSphere 6.0+应用服务器事务管理器的适配器，此适配器用于对应用服务器提供的高级事务的支持；
WebLogicJtaTransactionManager：位于org.springframework.transaction.jta包中，Spring提供的对WebLogic 8.1+应用服务器事务管理器的适配器，此适配器用于对应用服务器提供的高级事务的支持。

Spring不仅提供这些事务管理器，还提供对如JMS事务管理的管理器等，Spring提供一致的事务抽象如图9-1所示。

图9-1 Spring事务管理器

接下来让我们学习一下如何在Spring配置文件中定义事务管理器：

一、声明对本地事务的支持：

a)JDBC及iBATIS、MyBatis框架事务管理器

java代码：

通过dataSource属性指定需要事务管理的单个javax.sql.DataSource对象。

b)Jdo事务管理器

java代码：

通过persistenceManagerFactory属性指定需要事务管理的javax.jdo.PersistenceManagerFactory对象。

c)Jpa事务管理器

java代码：

通过entityManagerFactory属性指定需要事务管理的javax.persistence.EntityManagerFactory对象。

还需要为entityManagerFactory对象指定jpaDialect属性，该属性所对应的对象指定了如何获取连接对象、开启事务、关闭事务等事务管理相关的行为。

java代码：

d)Hibernate事务管理器

java代码：

通过entityManagerFactory属性指定需要事务管理的org.hibernate.SessionFactory对象。

二、Spring对全局事务的支持：

a)Jta事务管理器

java代码：

“dataSource”Bean表示从JNDI中获取的数据源，而txManager是JTA事务管理器，其中属性transactionManagerName指定了JTA事务管理器的JNDI名字，从而将事务管理委托给该事务管理器。

这只是最简单的配置方式，更复杂的形式请参考Spring Javadoc。

在此我们再介绍两个不依赖于应用服务器的开源JTA事务实现：JOTM和Atomikos Transactions Essentials。

JOTM：即基于Java开放事务管理器（Java Open Transaction Manager），实现JTA规范，能够运行在非应用服务器环境中，Web容器或独立Java SE环境，官网地址: http://jotm.objectweb.org/。
Atomikos Transactions Essentials：其为Atomikos开发的事务管理器，该产品属于开源产品，另外还一个商业的Extreme Transactions。官网地址为：http://www.atomikos.com。

对于以上JTA事务管理器使用，本文作者只是做演示使用，如果在实际项目中需要不依赖于应用服务器的JTA事务支持，需详细测试并选择合适的。

在本文中将使用Atomikos Transactions Essentials来进行演示JTA事务使用，由于Atomikos对hsqldb分布式支持不是很好，在Atomikos官网中列出如下兼容的数据库：Oracle、Informix、FirstSQL、DB2、MySQL、SQLServer、Sybase，这不代表其他数据库不支持，而是Atomikos团队没完全测试，在此作者决定使用derby内存数据库来演示JTA分布式事务。

1、首先准备jar包：

1.1、准备derby数据jar包，到下载的spring-framework-3.0.5.RELEASE-dependencies.zip中拷贝如下jar包：

com.springsource.org.apache.derby-10.5.1000001.764942.jar

1．2、准备Atomikos Transactions Essentials 对JTA事务支持的JTA包，此处使用AtomikosTransactionsEssentials3.5.5版本，到官网下载AtomikosTransactionsEssentials-3.5.5.zip，拷贝如下jar包到类路径：

atomikos-util.jar

transactions-api.jar

transactions-essentials-all.jar

transactions-jdbc.jar

transactions-jta.jar

transactions.jar

将如上jar包放在lib\atomikos目录下，并添加到类路径中。

2、接下来看一下在Spring中如何配置AtomikosTransactionsEssentials JTA事务：

2.1、配置分布式数据源：

java代码：

在此我们配置两个分布式数据源：使用com.atomikos.jdbc.AtomikosDataSourceBean来配置AtomikosTransactionsEssentials分布式数据源：

uniqueResourceName表示唯一资源名，如有多个数据源不可重复；
xaDataSourceClassName是具体分布式数据源厂商实现；
poolSize是数据连接池大小；
xaProperties属性指定具体厂商数据库属性，如databaseName指定数据库名，createDatabase表示启动derby内嵌数据库时创建databaseName指定的数据库。

在此我们还有定义了一个“dataSource2”Bean，其属性和“DataSource1”除以下不一样其他完全一样：

uniqueResourceName：因为不能重复，因此此处使用jdbc/test2；
databaseName：我们需要指定两个数据库，因此此处我们指定为test2。

2.2、配置事务管理器：

java代码：

atomikosTransactionManager：定义了AtomikosTransactionsEssentials事务管理器；
atomikosUserTransaction：定义UserTransaction，该Bean是线程安全的；
transactionManager：定义Spring事务管理器，transactionManager属性指定外部事务管理器（真正的事务管理者），使用userTransaction指定UserTransaction，该属性一般用于本地JTA实现，如果使用应用服务器事务管理器，该属性将自动从JNDI获取。

配置完毕，是不是也挺简单的，但是如果确实需要使用JTA事务，请首先选择应用服务器事务管理器，本示例不适合生产环境，如果非要运用到生产环境，可以考虑购买AtomikosTransactionsEssentials商业支持。

b)特定服务器事务管理器

Spring还提供了对特定应用服务器事务管理器集成的支持，目前提供对IBM WebSphere、BEA WebLogic、 Oracle OC4J应用服务器高级事务的支持，具体使用请参考Spring Javadoc。

现在我们已经学习如何配置事务管理器了，但是只有事务管理器Spring能自动进行事务管理吗？当然不能了，这需要我们来控制，目前Spring支持两种事务管理方式：编程式和声明式事务管理。接下来先看一下如何进行编程式事务管理吧。

9.3 编程式事务

9.3.1 编程式事务概述

所谓编程式事务指的是通过编码方式实现事务，即类似于JDBC编程实现事务管理。

Spring框架提供一致的事务抽象，因此对于JDBC还是JTA事务都是采用相同的API进行编程。

java代码：

此处可以看到使用UserTransaction而不是Connection连接进行控制事务，从而对于JDBC事务和JTA事务是采用不同API进行编程控制的，并且JTA和JDBC事务管理的异常也是不一样的。

具体如何使用JTA编程进行事务管理请参考cn.javass.spring.chapter9包下的TranditionalTransactionTest类。

而在Spring中将采用一致的事务抽象进行控制和一致的异常控制，即面向PlatformTransactionManager接口编程来控制事务。

9.3.1 Spring对编程式事务的支持

Spring中的事务分为物理事务和逻辑事务；

物理事务：就是底层数据库提供的事务支持，如JDBC或JTA提供的事务；
逻辑事务：是Spring管理的事务，不同于物理事务，逻辑事务提供更丰富的控制，而且如果想得到Spring事务管理的好处，必须使用逻辑事务，因此在Spring中如果没特别强调一般就是逻辑事务；

逻辑事务即支持非常低级别的控制，也有高级别解决方案：

低级别解决方案：

工具类：使用工具类获取连接（会话）和释放连接（会话），如使用org.springframework.jdbc.datasource包中的 DataSourceUtils 类来获取和释放具有逻辑事务功能的连接。当然对集成第三方ORM框架也提供了类似的工具类，如对Hibernate提供了SessionFactoryUtils工具类，JPA的EntityManagerFactoryUtils等，其他工具类都是使用类似***Utils命名；

java代码：

TransactionAwareDataSourceProxy：使用该数据源代理类包装需要Spring事务管理支持的数据源，该包装类必须位于最外层，主要用于遗留项目中可能直接使用数据源获取连接和释放连接支持或希望在Spring中进行混合使用各种持久化框架时使用，其内部实际使用 DataSourceUtils 工具类获取和释放真正连接；

java代码：

通过如上方式包装数据源后，可以在项目中使用物理事务编码的方式来获得逻辑事务的支持，即支持直接从DataSource获取连接和释放连接，且这些连接自动支持Spring逻辑事务；

高级别解决方案：

模板类：使用Spring提供的模板类，如JdbcTemplate、HibernateTemplate和JpaTemplate模板类等，而这些模板类内部其实是使用了低级别解决方案中的工具类来管理连接或会话；

Spring提供两种编程式事务支持：直接使用PlatformTransactionManager实现和使用TransactionTemplate模板类，用于支持逻辑事务管理。

如果采用编程式事务推荐使用TransactionTemplate模板类和高级别解决方案。

9.3.3 使用PlatformTransactionManager

首先让我们看下如何使用PlatformTransactionManager实现来进行事务管理：

1、数据源定义，此处使用第7章的配置文件，即“chapter7/ applicationContext-resources.xml”文件。

2、事务管理器定义（chapter9/applicationContext-jdbc.xml）：

java代码：

3、准备测试环境：

3.1、首先准备测试时使用的SQL：

java代码：

3.2、初始化Spring容器

java代码：

3.3、使用高级别方案JdbcTemplate来进行事务管理器测试：

java代码：

DefaultTransactionDefinition：事务定义，定义如隔离级别、传播行为等，即在本示例中隔离级别为ISOLATION_READ_COMMITTED（提交读），传播行为为PROPAGATION_REQUIRED（必须有事务支持，即如果当前没有事务，就新建一个事务，如果已经存在一个事务中，就加入到这个事务中）。
TransactionStatus：事务状态类，通过PlatformTransactionManager的getTransaction方法根据事务定义获取；获取事务状态后，Spring根据传播行为来决定如何开启事务；
JdbcTemplate：通过JdbcTemplate对象执行相应的SQL操作，且自动享受到事务支持，注意事务是线程绑定的，因此事务管理器可以运行在多线程环境；
txManager.commit(status)：提交status对象绑定的事务；
txManager.rollback(status)：当遇到异常时回滚status对象绑定的事务。

3.4、使用低级别解决方案来进行事务管理器测试：

java代码：

低级别方案中使用DataSourceUtils获取和释放连接，使用txManager开管理事务，而且面向JDBC编程，比起模板类方式来繁琐和复杂的多，因此不推荐使用该方式。在此就不介绍数据源代理类使用了，需要请参考platformTransactionManagerForLowLevelTest2测试方法。

到此事务管理是不是还很繁琐？必须手工提交或回滚事务，有没有更好的解决方案呢？Spring提供了TransactionTemplate模板类来简化事务管理。

9.3.4 使用TransactionTemplate

TransactionTemplate模板类用于简化事务管理，事务管理由模板类定义，而具体操作需要通过TransactionCallback回调接口或TransactionCallbackWithoutResult回调接口指定，通过调用模板类的参数类型为TransactionCallback或TransactionCallbackWithoutResult的execute方法来自动享受事务管理。

TransactionTemplate模板类使用的回调接口：

TransactionCallback：通过实现该接口的“T doInTransaction(TransactionStatus status) ”方法来定义需要事务管理的操作代码；
TransactionCallbackWithoutResult：继承TransactionCallback接口，提供“void doInTransactionWithoutResult(TransactionStatus status)”便利接口用于方便那些不需要返回值的事务操作代码。

1、接下来演示一下TransactionTemplate模板类如何使用：

java代码：

TransactionTemplate ：通过new TransactionTemplate(txManager)创建事务模板类，其中构造器参数为PlatformTransactionManager实现，并通过其相应方法设置事务定义，如事务隔离级别、传播行为等，此处未指定传播行为，其默认为PROPAGATION_REQUIRED；
TransactionCallbackWithoutResult：此处使用不带返回的回调实现，其doInTransactionWithoutResult方法实现中定义了需要事务管理的操作；
transactionTemplate.execute()：通过该方法执行需要事务管理的回调。

这样是不是简单多了，没有事务管理代码，而是由模板类来完成事务管理。

注：对于抛出Exception类型的异常且需要回滚时，需要捕获异常并通过调用status对象的setRollbackOnly()方法告知事务管理器当前事务需要回滚，如下所示：

java代码：

2、前边已经演示了JDBC事务管理，接下来演示一下JTA分布式事务管理：

java代码：

配置文件：使用此前定义的chapter9/applicationContext-jta-derby.xml；
jtaTXManager： JTA事务管理器；
derbyDataSource1和derbyDataSource2：derby数据源1和derby数据源2；
jdbcTemplate1和jdbcTemplate2：分别使用derbyDataSource1和derbyDataSource2构造的JDBC模板类；
transactionTemplate：使用jtaTXManager事务管理器的事务管理模板类，其隔离级别为提交读，传播行为默认为PROPAGATION_REQUIRED（必须有事务支持，即如果当前没有事务，就新建一个事务，如果已经存在一个事务中，就加入到这个事务中）；
jdbcTemplate1.update(CREATE_TABLE_SQL)：此处只有derbyDataSource1所代表的数据库创建了“test”表，而derbyDataSource2所代表的数据库没有此表；
TransactionCallbackWithoutResult：在此接口实现中定义了需要事务支持的操作：

jdbcTemplate1.update(INSERT_SQL, "test")：表示向数据库1中的test表中插入数据；

jdbcTemplate2.update(INSERT_SQL, "test")：表示向数据库2中的test表中插入数据，但数据库2没有此表将抛出异常，且JTA分布式事务将回滚；

Assert.assertEquals(originalCount, count)：用来验证事务是否回滚，验证结果返回为true，说明分布式事务回滚了。

到此我们已经会使用PlatformTransactionManager和TransactionTemplate进行简单事务处理了，那如何应用到实际项目中去呢？接下来让我们看下如何在实际项目中应用Spring管理事务。

接下来看一下如何将Spring管理事务应用到实际项目中，为简化演示，此处只定义最简单的模型对象和不完整的Dao层接口和Service层接口：

1、首先定义项目中的模型对象，本示例使用用户模型和用户地址模型：

模型对象一般放在项目中的model包里。

java代码：

2.1、定义Dao层接口：

java代码：

2.2、定义Dao层实现：

java代码：

3.1、定义Service层接口，一般使用“I×××Service”命名：

java代码：

3.2、定义Service层实现，一般使用“×××ServiceImpl”或“×××Service”命名：

java代码：

Service实现中需要Spring事务管理的部分应该使用TransactionTemplate模板类来包装执行。

4、定义TransactionTemplateUtils，用于简化获取TransactionTemplate模板类，工具类一般放在util包中：

java代码：

getDefaultTransactionTemplate用于获取传播行为为PROPAGATION_REQUIRED，隔离级别为ISOLATION_READ_COMMITTED的模板类。

5、数据源配置定义，此处使用第7章的配置文件，即“chapter7/ applicationContext-resources.xml”文件。

6、Dao层配置定义（chapter9/dao/applicationContext-jdbc.xml）：

java代码：

7、Service层配置定义（chapter9/service/applicationContext-service.xml）：

java代码：

8、准备测试需要的表创建语句，在TransactionTest测试类中添加如下静态变量：

java代码：

9、测试一下吧：

java代码：

从Spring容器中获取Service层对象，调用Service层对象持久化对象，大家有没有注意到Spring事务全部在Service层定义，为什么会在Service层定义，而不是Dao层定义呢？这是因为在服务层可能牵扯到业务逻辑，而每个业务逻辑可能调用多个Dao层方法，为保证这些操作的原子性，必须在Service层定义事务。

还有大家有没有注意到如果Service层的事务管理相当令人头疼，而且是侵入式的，有没有办法消除这些冗长的事务管理代码呢？这就需要Spring声明式事务支持，下一节将介绍无侵入式的声明式事务。

可能大家对事务定义中的各种属性有点困惑，如传播行为到底干什么用的？接下来将详细讲解一下事务属性。

9.3.5 事务属性

事务属性通过TransactionDefinition接口实现定义，主要有事务隔离级别、事务传播行为、事务超时时间、事务是否只读。

Spring提供TransactionDefinition接口默认实现DefaultTransactionDefinition，可以通过该实现类指定这些事务属性。

事务隔离级别：用来解决并发事务时出现的问题，其使用TransactionDefinition中的静态变量来指定：

ISOLATION_DEFAULT：默认隔离级别，即使用底层数据库默认的隔离级别；

ISOLATION_READ_UNCOMMITTED：未提交读；

ISOLATION_READ_COMMITTED：提交读，一般情况下我们使用这个；

ISOLATION_REPEATABLE_READ：可重复读；

ISOLATION_SERIALIZABLE：序列化。

可以使用DefaultTransactionDefinition类的setIsolationLevel(TransactionDefinition. ISOLATION_READ_COMMITTED)来指定隔离级别，其中此处表示隔离级别为提交读，也可以使用或setIsolationLevelName(“ISOLATION_READ_COMMITTED”)方式指定，其中参数就是隔离级别静态变量的名字，但不推荐这种方式。

事务传播行为：Spring管理的事务是逻辑事务，而且物理事务和逻辑事务最大差别就在于事务传播行为，事务传播行为用于指定在多个事务方法间调用时，事务是如何在这些方法间传播的，Spring共支持7种传播行为：

Required：必须有逻辑事务，否则新建一个事务，使用PROPAGATION_REQUIRED指定，表示如果当前存在一个逻辑事务，则加入该逻辑事务，否则将新建一个逻辑事务，如图9-2和9-3所示；

图9-2 Required传播行为

图9-3 Required传播行为抛出异常情况

在前边示例中就是使用的Required传播行为：

一、在调用userService对象的save方法时，此方法用的是Required传播行为且此时Spring事务管理器发现还没开启逻辑事务，因此Spring管理器觉得开启逻辑事务，

二、在此逻辑事务中调用了addressService对象的save方法，而在save方法中发现同样用的是Required传播行为，因此使用该已经存在的逻辑事务；

三、在返回到addressService对象的save方法，当事务模板类执行完毕，此时提交并关闭事务。

因此userService对象的save方法和addressService的save方法属于同一个物理事务，如果发生回滚，则两者都回滚。

接下来测试一下该传播行为如何执行吧：

一、正确提交测试，如上一节的测试，在此不再演示；

二、回滚测试，修改AddressServiceImpl的save方法片段：

java代码：

为

java代码：

二、修改UserServiceImpl的save方法片段：

java代码：

为

java代码：

如果该业务方法执行时事务被标记为回滚，则不管在此是否捕获该异常都将发生回滚，因为处于同一逻辑事务。

三、修改测试方法片段:

java代码：

为如下形式：

java代码：

Assert断言中countAll方法都返回0，说明事务回滚了，即说明两个业务方法属于同一个物理事务，即使在userService对象的save方法中将异常捕获，由于addressService对象的save方法抛出异常，即事务管理器将自动标识当前事务为需要回滚。

RequiresNew：创建新的逻辑事务，使用PROPAGATION_REQUIRES_NEW指定，表示每次都创建新的逻辑事务（物理事务也是不同的）如图9-4和9-5所示：

图9-4 RequiresNew传播行为

图9-5 RequiresNew传播行为并抛出异常

接下来测试一个该传播行为如何执行吧：

1、将如下获取事务模板方式

java代码：

替换为如下形式，表示传播行为为RequiresNew：

java代码：

2、执行如下测试，发现执行结果是正确的：

java代码：

3、修改UserServiceImpl的save方法片段

java代码：

为如下形式，表示userServiceImpl类的save方法将发生回滚，而AddressServiceImpl类的方法由于在抛出异常前执行，将成功提交事务到数据库：

java代码：

4、修改测试方法片段：

java代码：

为如下形式：

java代码：

Assert断言中调用userService对象countAll方法返回0，说明该逻辑事务作用域回滚，而调用addressService对象的countAll方法返回1，说明该逻辑事务作用域正确提交。因此这是不正确的行为，因为用户和地址应该是一一对应的，不应该发生这种情况，因此此处正确的传播行为应该是Required。

该传播行为执行流程（正确提交情况）：

一、当执行userService对象的save方法时，由于传播行为是RequiresNew，因此创建一个新的逻辑事务（物理事务也是不同的）；

二、当执行到addressService对象的save方法时，由于传播行为是RequiresNew，因此首先暂停上一个逻辑事务并创建一个新的逻辑事务（物理事务也是不同的）;

三、addressService对象的save方法执行完毕后，提交逻辑事务（并提交物理事务）并重新恢复上一个逻辑事务，继续执行userService对象的save方法内的操作；

四、最后userService对象的save方法执行完毕，提交逻辑事务（并提交物理事务）；

五、userService对象的save方法和addressService对象的save方法不属于同一个逻辑事务且也不属于同一个物理事务。

Supports：支持当前事务，使用PROPAGATION_SUPPORTS指定，指如果当前存在逻辑事务，就加入到该逻辑事务，如果当前没有逻辑事务，就以非事务方式执行，如图9-6和9-7所示：

图9-6 Required+Supports传播行为

图9-7 Supports+Supports传播行为

NotSupported：不支持事务，如果当前存在事务则暂停该事务，使用PROPAGATION_NOT_SUPPORTED指定，即以非事务方式执行，如果当前存在逻辑事务，就把当前事务暂停，以非事务方式执行，如图9-8和9-9所示：

图9-8 Required+NotSupported传播行为

图9-9 Supports+NotSupported传播行为

Mandatory：必须有事务，否则抛出异常，使用PROPAGATION_MANDATORY指定，使用当前事务执行，如果当前没有事务，则抛出异常（IllegalTransactionStateException），如图9-10和9-11所示：

图9-10 Required+Mandatory传播行为

图9-11 Supports+Mandatory传播行为

Never：不支持事务，如果当前存在是事务则抛出异常，使用PROPAGATION_NEVER指定，即以非事务方式执行，如果当前存在事务，则抛出异常（IllegalTransactionStateException），如图9-12和9-13所示：

图9-12 Required+Never传播行为

图9-13 Supports+Never传播行为

Nested：嵌套事务支持，使用PROPAGATION_NESTED指定，如果当前存在事务，则在嵌套事务内执行，如果当前不存在事务，则创建一个新的事务，嵌套事务使用数据库中的保存点来实现，即嵌套事务回滚不影响外部事务，但外部事务回滚将导致嵌套事务回滚，如图9-14和9-15所示：

图9-14 Required+Nested传播行为

图9-15 Nested+Nested传播行为

Nested和RequiresNew的区别：

1、 RequiresNew每次都创建新的独立的物理事务，而Nested只有一个物理事务；

2、 Nested嵌套事务回滚或提交不会导致外部事务回滚或提交，但外部事务回滚将导致嵌套事务回滚，而 RequiresNew由于都是全新的事务，所以之间是无关联的；

3、 Nested使用JDBC 3的保存点实现，即如果使用低版本驱动将导致不支持嵌套事务。

使用嵌套事务，必须确保具体事务管理器实现的nestedTransactionAllowed属性为true，否则不支持嵌套事务，如DataSourceTransactionManager默认支持，而HibernateTransactionManager默认不支持，需要我们来开启。

对于事务传播行为我们只演示了Required和RequiresNew，其他传播行为类似，如果对这些事务传播行为不太会使用，请参考chapter9包下的TransactionTest测试类中的testPropagation方法，方法内有详细示例。

事务超时：设置事务的超时时间，单位为秒，默认为-1表示使用底层事务的超时时间；

使用如setTimeout(100)来设置超时时间，如果事务超时将抛出org.springframework.transaction.TransactionTimedOutException异常并将当前事务标记为应该回滚，即超时后事务被自动回滚；

可以使用具体事务管理器实现的defaultTimeout属性设置默认的事务超时时间，如DataSourceTransactionManager. setDefaultTimeout(10)。

事务只读：将事务标识为只读，只读事务不修改任何数据；

对于JDBC只是简单的将连接设置为只读模式，对于更新将抛出异常；

而对于一些其他ORM框架有一些优化作用，如在Hibernate中，Spring事务管理器将执行“session.setFlushMode(FlushMode.MANUAL)”即指定Hibernate会话在只读事务模式下不用尝试检测和同步持久对象的状态的更新。

如果使用设置具体事务管理的validateExistingTransaction属性为true（默认false），将确保整个事务传播链都是只读或都不是只读，如图9-16是正确的事务只读设置，而图9-17是错误的事务只读设置：

图9-16 正确的事务只读设置

图9-17 错误的事务只读设置

如图10-17，对于错误的事务只读设置将抛出IllegalTransactionStateException异常，并伴随“Participating transaction with definition [……] is not marked as read-only……”信息，表示参与的事务只读属性设置错误。

大家有没有感觉到编程式实现事务管理是不是很繁琐冗长，重复，而且是侵入式的，因此发展到这Spring决定使用配置方式实现事务管理。

9.3.6 配置方式实现事务管理

在Spring2.x之前为了解决编程式事务管理的各种不好问题，Spring提出使用配置方式实现事务管理，配置方式利用代理机制实现，即使有TransactionProxyFactoryBean类来为目标类代理事务管理。

接下来演示一下具体使用吧：

1、重新定义业务类实现，在业务类中无需显示的事务管理代码：

java代码：

从以上业务类中可以看出，没有事务管理的代码，即没有侵入式的代码。

2、在chapter9/service/applicationContext-service.xml配置文件中添加如下配置：

2.1、首先添加目标类定义：

java代码：

2.2、配置TransactionProxyFactoryBean类：

java代码：

<bean id="transactionProxyParent" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"  abstract="true">  <property name="transactionManager" ref="txManager"/>  <property name="transactionAttributes">  <props>  <prop key="save*">  PROPAGATION_REQUIRED,  ISOLATION_READ_COMMITTED,  timeout_10,  -Exception,  +NoRollBackException  </prop>  <prop key="*">  PROPAGATION_REQUIRED,  ISOLATION_READ_COMMITTED,  readOnly  </prop>  </props>
</property>
</bean>

TransactionProxyFactoryBean：用于为目标业务类创建代理的Bean；
abstract="true"：表示该Bean是抽象的，用于去除重复配置；
transactionManager：事务管理器定义；
transactionAttributes：表示事务属性定义：
PROPAGATION_REQUIRED,ISOLATION_READ_COMMITTED,timeout_10,-Exception,+NoRollBackException：事务属性定义，Required传播行为，提交读隔离级别，事务超时时间为10秒，将对所有Exception异常回滚，而对于抛出NoRollBackException异常将不发生回滚而是提交；
PROPAGATION_REQUIRED,ISOLATION_READ_COMMITTED,readOnly：事务属性定义，Required传播行为，提交读隔离级别，事务是只读的，且只对默认的RuntimeException异常回滚；
<prop key="save*">：表示将代理以save开头的方法，即当执行到该方法时会为该方法根据事务属性配置来开启/关闭事务；
<prop key="*">：表示将代理其他所有方法，但需要注意代理方式，默认是JDK代理，只有public方法能代理；

注：事务属性的传播行为和隔离级别使用TransactionDefinition静态变量名指定；事务超时使用“timeout_超时时间”指定，事务只读使用“readOnly”指定，需要回滚的异常使用“-异常”指定，不需要回滚的异常使用“+异常”指定，默认只对RuntimeException异常回滚。

需要特别注意“-异常”和“+异常”中“异常”只是真实异常的部分名，内部使用如下方式判断：

java代码：

因此异常定义时需要特别注意，配置中定义的异常只是真实异常的部分名。

2.3、定义代理Bean：

java代码：

代理Bean通过集成抽象Bean“transactionProxyParent”，并通过target属性设置目标Bean，在实际使用中应该使用该代理Bean。

3、修改测试方法并测试该配置方式是否好用：

将TransactionTest 类的testServiceTransaction测试方法拷贝一份命名为testConfigTransaction：

并在testConfigTransaction测试方法内将：

java代码：

替换为：

java代码：

4、执行测试，测试正常通过，说明该方式能正常工作，当调用save方法时将匹配到“<prop key="save*">”定义，而countAll将匹配到“<prop key="save*">”定义，底层代理会应用相应定义中的事务属性来创建或关闭事务。

图9-18 代理方式实现事务管理

如图9-18，代理方式实现事务管理只是将硬编码的事务管理代码转移到代理中去由代理实现，在代理中实现事务管理。

注：在代理模式下，默认只有通过代理对象调用的方法才能应用相应的事务属性，而在目标方法内的“自我调用”是不会应用相应的事务属性的，即被调用方法不会应用相应的事务属性，而是使用调用方法的事务属性。

如图9-19所示，在目标对象targetUserService的save方法内调用事务方法“this.otherTransactionMethod()”将不会应用配置的传播行为RequriesNew，开启新事务，而是使用save方法的已开启事务，如果非要这样使用如下方式实现：

1、修改TransactionProxyFactoryBean配置定义，添加exposeProxy属性为true；

2、在业务方法内通过代理对象调用相应的事务方放，如 “((IUserService)AopContext.currentProxy()).otherTransactionMethod()”即可应用配置的事务属性。

3、使用这种方式属于侵入式，不推荐使用，除非必要。

图9-19 代理方式下的自我调用

配置方式也好麻烦啊，每个业务实现都需要配置一个事务代理，发展到这，Spring想出更好的解决方案，Spring2.0及之后版本提出使用新的“<tx:tags/>”方式配置事务，从而无需为每个业务实现配置一个代理。

9.4 声明式事务

9.4.1 声明式事务概述

从上节编程式实现事务管理可以深刻体会到编程式事务的痛苦，即使通过代理配置方式也是不小的工作量。

本节将介绍声明式事务支持，使用该方式后最大的获益是简单，事务管理不再是令人痛苦的，而且此方式属于无侵入式，对业务逻辑实现无影响。

接下来先来看看声明式事务如何实现吧。

9.4.2 声明式实现事务管理

1、定义业务逻辑实现，此处使用ConfigUserServiceImpl和ConfigAddressServiceImpl：

2、定义配置文件（chapter9/service/ applicationContext-service-declare.xml）：

2.1、XML命名空间定义，定义用于事务支持的tx命名空间和AOP支持的aop命名空间：

java代码：

2.2、业务实现配置，非常简单，使用以前定义的非侵入式业务实现：

java代码：

2.3、事务相关配置：

java代码：

<tx:advice>：事务通知定义，用于指定事务属性，其中“transaction-manager”属性指定事务管理器，并通过< tx:attributes >指定具体需要拦截的方法；
<tx:method name="save*">：表示将拦截以save开头的方法，被拦截的方法将应用配置的事务属性：propagation="REQUIRED"表示传播行为是Required，isolation="READ_COMMITTED"表示隔离级别是提交读；
<tx:method name="*">：表示将拦截其他所有方法，被拦截的方法将应用配置的事务属性：propagation="REQUIRED"表示传播行为是Required，isolation="READ_COMMITTED"表示隔离级别是提交读，read-only="true"表示事务只读；

<aop:config>：AOP相关配置：
<aop:pointcut/>：切入点定义，定义名为"serviceMethod"的aspectj切入点，切入点表达式为"execution(* cn..chapter9.service..*.*(..))"表示拦截cn包及子包下的chapter9. service包及子包下的任何类的任何方法；
<aop:advisor>：Advisor定义，其中切入点为serviceMethod，通知为txAdvice。

从配置中可以看出，将对cn包及子包下的chapter9. service包及子包下的任何类的任何方法应用“txAdvice”通知指定的事务属性。

3、修改测试方法并测试该配置方式是否好用：

将TransactionTest 类的testServiceTransaction测试方法拷贝一份命名为testDeclareTransaction：

并在testDeclareTransaction测试方法内将：

java代码：

替换为：

java代码：

4、执行测试，测试正常通过，说明该方式能正常工作，当调用save方法时将匹配到事务通知中定义的“<tx:method name="save*">”中指定的事务属性，而调用countAll方法时将匹配到事务通知中定义的“<tx:method name="*">”中指定的事务属性。

声明式事务是如何实现事务管理的呢？还记不记得TransactionProxyFactoryBean实现配置式事务管理，配置式事务管理是通过代理方式实现，而声明式事务管理同样是通过AOP代理方式实现。

声明式事务通过AOP代理方式实现事务管理，利用环绕通知TransactionInterceptor实现事务的开启及关闭，而TransactionProxyFactoryBean内部也是通过该环绕通知实现的，因此可以认为是<tx:tags/>帮你定义了TransactionProxyFactoryBean，从而简化事务管理。

了解了实现方式后，接下来详细学习一下配置吧：

9.4.4 <tx:advice/>配置详解

声明式事务管理通过配置<tx:advice/>来定义事务属性，配置方式如下所示：

java代码：

<tx:advice>：id用于指定此通知的名字， transaction-manager用于指定事务管理器，默认的事务管理器名字为“transactionManager”；
<tx:method>：用于定义事务属性即相关联的方法名；

name：定义与事务属性相关联的方法名，将对匹配的方法应用定义的事务属性，可以使用“*”通配符来匹配一组或所有方法，如“save*”将匹配以save开头的方法，而“*”将匹配所有方法；

propagation：事务传播行为定义，默认为“REQUIRED”，表示Required，其值可以通过TransactionDefinition的静态传播行为变量的“PROPAGATION_”后边部分指定，如“TransactionDefinition.PROPAGATION_REQUIRED”可以使用“REQUIRED”指定；

isolation：事务隔离级别定义；默认为“DEFAULT”，其值可以通过TransactionDefinition的静态隔离级别变量的“ISOLATION_”后边部分指定，如“TransactionDefinition. ISOLATION_DEFAULT”可以使用“DEFAULT”指定：

timeout：事务超时时间设置，单位为秒，默认-1，表示事务超时将依赖于底层事务系统；

read-only：事务只读设置，默认为false，表示不是只读；

rollback-for：需要触发回滚的异常定义，以“，”分割，默认任何RuntimeException 将导致事务回滚，而任何Checked Exception 将不导致事务回滚；异常名字定义和TransactionProxyFactoryBean中含义一样

no-rollback-for：不被触发进行回滚的 Exception(s)；以“，”分割；异常名字定义和TransactionProxyFactoryBean中含义一样；

记不记得在配置方式中为了解决“自我调用”而导致的不能设置正确的事务属性问题，使用“((IUserService)AopContext.currentProxy()).otherTransactionMethod()”方式解决，在声明式事务要得到支持需要使用<aop:config expose-proxy="true">来开启。

9.4.5 多事务语义配置及最佳实践

什么是多事务语义？说白了就是为不同的Bean配置不同的事务属性，因为我们项目中不可能就几个Bean，而可能很多，这可能需要为Bean分组，为不同组的Bean配置不同的事务语义。在Spring中，可以通过配置多切入点和多事务通知并通过不同方式组合使用即可。

1、首先看下声明式事务配置的最佳实践吧：

java代码：

该声明式事务配置可以应付常见的CRUD接口定义，并实现事务管理，我们只需修改切入点表达式来拦截我们的业务实现从而对其应用事务属性就可以了，如果还有更复杂的事务属性直接添加即可，即

如果我们有一个batchSaveOrUpdate方法需要“REQUIRES_NEW”事务传播行为，则直接添加如下配置即可：

java代码：

2、接下来看一下多事务语义配置吧，声明式事务最佳实践中已经配置了通用事务属性，因此可以针对需要其他事务属性的业务方法进行特例化配置：

java代码：

该声明将对切入点匹配的方法所在事务应用“Never”传播行为。

多事务语义配置时，切入点一定不要叠加，否则将应用两次事务属性，造成不必要的错误及麻烦。

9.4.6 @Transactional实现事务管理

对声明式事务管理，Spring提供基于@Transactional注解方式来实现，但需要Java 5+。

注解方式是最简单的事务配置方式，可以直接在Java源代码中声明事务属性，且对于每一个业务类或方法如果需要事务都必须使用此注解。

接下来学习一下注解事务的使用吧：

1、定义业务逻辑实现：

java代码：

2、定义配置文件（chapter9/service/ applicationContext-service-annotation.xml）：

2.1、XML命名空间定义，定义用于事务支持的tx命名空间和AOP支持的aop命名空间：

java代码：

2.2、业务实现配置，非常简单，使用以前定义的非侵入式业务实现：

java代码：

<bean id="userService" class="cn.javass.spring.chapter9.service.impl.ConfigUserServiceImpl">  <property name="userDao" ref="userDao"/>  <property name="addressService" ref="addressService"/>
</bean>
<bean id="addressService" class="cn.javass.spring.chapter9.service.impl.ConfigAddressServiceImpl">  <property name="addressDao" ref="addressDao"/>
</bean>

2.3、事务相关配置：

java代码：

使用如上配置已支持声明式事务。

3、修改测试方法并测试该配置方式是否好用：

将TransactionTest 类的testServiceTransaction测试方法拷贝一份命名为testAnntationTransactionTest：

将测试代码片段：

java代码：

替换为：

java代码：

将测试代码段

java代码：

替换为：

java代码：

4、执行测试，测试正常通过，说明该方式能正常工作，因为在AnnotationAddressServiceImpl类的save方法中抛出异常，因此事务需要回滚，所以两个countAll操作都返回0。

9.4.7 @Transactional配置详解

Spring提供的<tx:annotation-driven/>用于开启对注解事务管理的支持，从而能识别Bean类上的@Transactional注解元数据，其具有以下属性：

transaction-manager：指定事务管理器名字，默认为transactionManager，当使用其他名字时需要明确指定；
proxy-target-class：表示将使用的代码机制，默认false表示使用JDK代理，如果为true将使用CGLIB代理
order：定义事务通知顺序，默认Ordered.LOWEST_PRECEDENCE，表示将顺序决定权交给AOP来处理。

Spring使用@Transaction来指定事务属性，可以在接口、类或方法上指定，如果类和方法上都指定了@Transaction，则方法上的事务属性被优先使用，具体属性如下：

value：指定事务管理器名字，默认使用<tx:annotation-driven/>指定的事务管理器，用于支持多事务管理器环境；
propagation：指定事务传播行为，默认为Required，使用Propagation.REQUIRED指定；
isolation：指定事务隔离级别，默认为“DEFAULT”，使用Isolation.DEFAULT指定；
readOnly：指定事务是否只读，默认false表示事务非只读；
timeout：指定事务超时时间，以秒为单位，默认-1表示事务超时将依赖于底层事务系统；
rollbackFor：指定一组异常类，遇到该类异常将回滚事务；
rollbackForClassname：指定一组异常类名字，其含义与<tx:method>中的rollback-for属性语义完全一样；
noRollbackFor：指定一组异常类，即使遇到该类异常也将提交事务，即不回滚事务；
noRollbackForClassname：指定一组异常类名字，其含义与<tx:method>中的no-rollback-for属性语义完全一样；

Spring提供的@Transaction注解事务管理内部同样利用环绕通知TransactionInterceptor实现事务的开启及关闭。

使用@Transactional注解事务管理需要特别注意以下几点：

如果在接口、实现类或方法上都指定了@Transactional 注解，则优先级顺序为方法>实现类>接口；
建议只在实现类或实现类的方法上使用@Transactional，而不要在接口上使用，这是因为如果使用JDK代理机制是没问题，因为其使用基于接口的代理；而使用使用CGLIB代理机制时就会遇到问题，因为其使用基于类的代理而不是接口，这是因为接口上的@Transactional注解是“不能继承的”；

具体请参考基于JDK动态代理和CGLIB动态代理的实现Spring注解管理事务（@Trasactional）到底有什么区别。

在Spring代理机制下(不管是JDK动态代理还是CGLIB代理)，“自我调用”同样不会应用相应的事务属性，其语义和<tx:tags>中一样；
默认只对RuntimeException异常回滚；
在使用Spring代理时，默认只有在public可见度的方法的@Transactional 注解才是有效的，其它可见度（protected、private、包可见）的方法上即使有@Transactional 注解也不会应用这些事务属性的，Spring也不会报错，如果你非要使用非公共方法注解事务管理的话，可考虑使用AspectJ。

9.4.9 与其他AOP通知协作

Spring声明式事务实现其实就是Spring AOP+线程绑定实现，利用AOP实现开启和关闭事务，利用线程绑定（ThreadLocal）实现跨越多个方法实现事务传播。

由于我们不可能只使用一个事务通知，可能还有其他类型事务通知，而且如果这些通知中需要事务支持怎么办？这就牵扯到通知执行顺序的问题上了，因此如果可能与其他AOP通知协作的话，而且这些通知中需要使用声明式事务管理支持，事务通知应该具有最高优先级。

9.4.10 声明式or编程式

编程式事务时不推荐的，即使有很少事务操作，Spring发展到现在，没有理由使用编程式事务，只有在为了深入理解Spring事务管理才需要学习编程式事务使用。

推荐使用声明式事务，而且强烈推荐使用<tx:tags>方式的声明式事务，因为其是无侵入代码的，可以配置模板化的事务属性并运用到多个项目中。

而@Transaction注解事务，可以使用，不过作者更倾向于使用<tx:tags>声明式事务。

能保证项目正常工作的事务配置就是最好的。

9.4.11 混合事务管理

所谓混合事务管理就是混合多种数据访问技术使用，如混合使用Spring JDBC + Hibernate，接下来让我们学习一下常见混合事务管理：

1、 Hibernate + Spring JDBC/iBATIS：使用HibernateTransactionManager即可支持；

2、 JPA + Spring JDBC/iBATIS：使用JpaTransactionManager即可支持；

3、 JDO + Spring JDBC/iBATIS：使用JtaTransactionManager即可支持；

混合事务管理最大问题在于如果我们使用第三方ORM框架，如Hibernate，会遇到一级及二级缓存问题，尤其是二级缓存可能造成如使用Spring JDBC和Hibernate查询出来的数据不一致等。

因此不建议使用这种混合使用和混合事务管理。