详解spring事务属性

Spring声明式事务让我们从复杂的事务处理中得到解脱。使得我们再也无需要去处理获得连接、关闭连接、事务提交和回滚等这些操作。再也无需要我们在与事务相关的方法中处理大量的try…catch…finally代码。 
我们在使用Spring声明式事务时，有一个非常重要的概念就是事务属性。事务属性通常由事务的传播行为，事务的隔离级别，事务的超时值和事务只读标志组成。我们在进行事务划分时，需要进行事务定义，也就是配置事务的属性。 
Spring在TransactionDefinition接口中定义这些属性,以供PlatfromTransactionManager使用, PlatfromTransactionManager是spring事务管理的核心接口。

Java代码 

1. TransactionDefinition  
2. public interface TransactionDefinition {  
3.     int getPropagationBehavior();  
4.     int getIsolationLevel();  
5.     int getTimeout();  
6.     boolean isReadOnly();  
7. }  

getTimeout()方法，它返回事务必须在多少秒内完成。 
isReadOnly(),事务是否只读，事务管理器能够根据这个返回值进行优化，确保事务是只读的。 
getIsolationLevel()方法返回事务的隔离级别，事务管理器根据它来控制另外一个事务可以看到本事务内的哪些数据。 

在TransactionDefinition接口中定义了五个不同的事务隔离级别 
ISOLATION_DEFAULT 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应 
ISOLATION_READ_UNCOMMITTED 这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。 
  例如: 
  Mary的原工资为1000,财务人员将Mary的工资改为了8000，但未提交事务 

Java代码 

1. Connection con1 = getConnection();  
2. con.setAutoCommit(false);  
3. update employee set salary = 8000 where empId ="Mary";  

与此同时，Mary正在读取自己的工资 

Java代码 

1. Connection con2 = getConnection();  
2. select  salary from employee where empId ="Mary";  
3. con2.commit();  

Mary发现自己的工资变为了8000，欢天喜地！ 
而财务发现操作有误，而回滚了事务,Mary的工资又变为了1000 

Java代码 

1. //con1  
2.   con1.rollback();  

像这样,Mary记取的工资数8000是一个脏数据。 

ISOLATION_READ_COMMITTED  保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。 

ISOLATION_REPEATABLE_READ  这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。 

在事务1中，Mary 读取了自己的工资为1000,操作并没有完成 

Java代码 

1. con1 = getConnection();  
2. select salary from employee empId ="Mary";  

在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务. 

Java代码 

1. con2 = getConnection();  
2. update employee set salary = 2000;  
3. con2.commit();  

在事务1中，Mary 再次读取自己的工资时，工资变为了2000 

Java代码 

1. //con1  
2. select salary from employee empId ="Mary";  

在一个事务中前后两次读取的结果并不致，导致了不可重复读。 
使用ISOLATION_REPEATABLE_READ可以避免这种情况发生。 

ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻像读。 

目前工资为1000的员工有10人。 
事务1,读取所有工资为1000的员工。 

Java代码 

1. con1 = getConnection();  
2. Select * from employee where salary =1000;  

共读取10条记录 

这时另一个事务向employee表插入了一条员工记录，工资也为1000 

Java代码 

1. con2 = getConnection();  
2. Insert into employee(empId,salary) values("Lili",1000);  
3. con2.commit();  

事务1再次读取所有工资为1000的员工 

Java代码 

1. //con1  
2. select * from employee where salary =1000;  

共读取到了11条记录，这就产生了幻像读。 
ISOLATION_SERIALIZABLE能避免这样的情况发生。但是这样也耗费了最大的资源。 

getPropagationBehavior()返回事务的传播行为，由是否有一个活动的事务来决定一个事务调用。 

在TransactionDefinition接口中定义了七个事务传播行为。 

PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。

Java代码 

1. //事务属性 PROPAGATION_REQUIRED  
2. methodA{  
3. ……  
4. methodB();  
5. ……  
6. }  
7.   
8. //事务属性 PROPAGATION_REQUIRED  
9. methodB{  
10.    ……  
11. }  

使用spring声明式事务，spring使用AOP来支持声明式事务，会根据事务属性，自动在方法调用之前决定是否开启一个事务，并在方法执行之后决定事务提交或回滚事务。 

单独调用methodB方法 

Java代码 

1. main{  
2.   metodB();  
3. }  

相当于 

Java代码 

1. Main{  
2. Connection con=null;  
3.   
4.    rry{  
5.       con = getConnection();  
6.       con.setAutoCommit(false);  
7. //方法调用  
8. methodB();  
9. //提交事务  
10. con.commit();  
11. }  
12. Catch(RuntimeException ex){  
13.   //回滚事务  
14.   con.rollback();    
15. }  
16. finally{  
17.   //释放资源  
18.   closeCon();  
19. }  
20. }  

Spring保证在methodB方法中所有的调用都获得到一个相同的连接。在调用methodB时，没有一个存在的事务，所以获得一个新的连接，开启了一个新的事务。 

单独调用MethodA时，在MethodA内又会调用MethodB. 

执行效果相当于 

Java代码 

1. main{  
2.    Connection con = null;  
3.    try{  
4.       con = getConnection();  
5.       methodA();  
6.       con.commit();  
7. }  
8. cathc(RuntimeException ex){  
9.  con.rollback();  
10. }  
11. finally{  
12.   closeCon();  
13. }   
14. }  

调用MethodA时，环境中没有事务，所以开启一个新的事务. 
当在MethodA中调用MethodB时，环境中已经有了一个事务，所以methodB就加入当前事务。 

PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。但是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。

Java代码 

1. //事务属性 PROPAGATION_REQUIRED   
2. methodA(){  
3.   methodB();  
4. }  
5.   
6. //事务属性 PROPAGATION_SUPPORTS   
7. methodB(){  
8.   ……  
9. }  

单纯的调用methodB时，methodB方法是非事务的执行的。 
当调用methdA时,methodB则加入了methodA的事务中,事务地执行。 

PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。

Java代码 

1. //事务属性 PROPAGATION_REQUIRED   
2. methodA(){  
3.   methodB();  
4. }  
5.   
6. //事务属性 PROPAGATION_MANDATORY   
7. methodB(){  
8.   ……  
9. }  

当单独调用methodB时，因为当前没有一个活动的事务，则会抛出异常 
throw new IllegalTransactionStateException("Transaction propagation 'mandatory' but no existing transaction found"); 

当调用methodA时，methodB则加入到methodA的事务中，事务地执行。 

PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。

Java代码 

1. //事务属性 PROPAGATION_REQUIRED   
2. methodA(){  
3.   doSomeThingA();  
4. methodB();  
5. doSomeThingB();  
6. }  
7.   
8. //事务属性 PROPAGATION_REQUIRES_NEW   
9. methodB(){  
10.   ……  
11. }  

当单独调用methodB时，相当于把methodb声明为REQUIRED。开启一个新的事务，事务地执行。 

当调用methodA时 

Java代码 

1. main(){  
2.   methodA();  
3. }  

情况有些大不一样.相当于下面的效果。 

Java代码 

1. main(){  
2.  TransactionManager tm = null;  
3. try{  
4.   //获得一个JTA事务管理器  
5.    tm = getTransactionManager();  
6.    tm.begin();//开启一个新的事务  
7.    Transaction ts1 = tm.getTransaction();  
8.    doSomeThing();  
9.    tm.suspend();//挂起当前事务  
10.    try{  
11.      tm.begin();//重新开启第二个事务  
12.      Transaction ts2 = tm.getTransaction();  
13.      methodB();  
14.      ts2.commit();//提交第二个事务  
15.        
16.    }  
17.   Catch(RunTimeException ex){  
18.      ts2.rollback();//回滚第二个事务  
19.   }  
20.   finally{  
21.     //释放资源  
22.   }  
23.    //methodB执行完后，复恢第一个事务  
24.    tm.resume(ts1);  
25. doSomeThingB();  
26.    ts1.commit();//提交第一个事务  
27. }  
28. catch(RunTimeException ex){  
29.   ts1.rollback();//回滚第一个事务  
30. }  
31. finally{  
32.   //释放资源  
33. }  
34. }  

在这里，我把ts1称为外层事务，ts2称为内层事务。从上面的代码可以看出，ts2与ts1是两个独立的事务，互不相干。Ts2是否成功并不依赖于ts1。如果methodA方法在调用methodB方法后的doSomeThingB方法失败了，而methodB方法所做的结果依然被提交。而除了methodB之外的其它代码导致的结果却被回滚了。 
使用PROPAGATION_REQUIRES_NEW,需要使用JtaTransactionManager作为事务管理器。 

PROPAGATION_NOT_SUPPORTED  总是非事务地执行，并挂起任何存在的事务。

Java代码 

1. //事务属性 PROPAGATION_REQUIRED   
2. methodA(){  
3.   doSomeThingA();  
4. methodB();  
5. doSomeThingB();  
6. }  
7.   
8. //事务属性 PROPAGATION_NOT_SUPPORTED   
9. methodB(){  
10.   ……  
11. }  

当单独调用methodB时，不启用任何事务机制，非事务地执行。 
当调用methodA时，相当于下面的效果

Java代码 

1. main(){  
2.  TransactionManager tm = null;  
3. try{  
4.   //获得一个JTA事务管理器  
5.    tm = getTransactionManager();  
6.    tm.begin();//开启一个新的事务  
7.    Transaction ts1 = tm.getTransaction();  
8.    doSomeThing();  
9.    tm.suspend();//挂起当前事务  
10.      methodB();  
11.    //methodB执行完后，复恢第一个事务  
12.    tm.resume(ts1);  
13. doSomeThingB();  
14.    ts1.commit();//提交第一个事务  
15. }  
16. catch(RunTimeException ex){  
17.   ts1.rollback();//回滚第一个事务  
18. }  
19. finally{  
20.   //释放资源  
21. }  
22. }  

使用PROPAGATION_NOT_SUPPORTED,也需要使用JtaTransactionManager作为事务管理器。 

PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常

Java代码 

1. //事务属性 PROPAGATION_REQUIRED   
2. methodA(){  
3.   doSomeThingA();  
4. methodB();  
5. doSomeThingB();  
6. }  
7.   
8. //事务属性 PROPAGATION_NEVER   
9. methodB(){  
10.   ……  
11. }  

单独调用methodB，则非事务的执行。 
调用methodA则会抛出异常 
throw new IllegalTransactionStateException( 
"Transaction propagation 'never' but existing transaction found"); 


PROPAGATION_NESTED如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行 

这是一个嵌套事务,使用JDBC 3.0驱动时,仅仅支持DataSourceTransactionManager作为事务管理器。需要JDBC 驱动的java.sql.Savepoint类。有一些JTA的事务管理器实现可能也提供了同样的功能。 

使用PROPAGATION_NESTED，还需要把PlatformTransactionManager的nestedTransactionAllowed属性设为true; 
而nestedTransactionAllowed属性值默认为false; 

Java代码 

1. //事务属性 PROPAGATION_REQUIRED   
2. methodA(){  
3.   doSomeThingA();  
4. methodB();  
5. doSomeThingB();  
6. }  
7.   
8. //事务属性 PROPAGATION_NESTED  
9. methodB(){  
10.   ……  
11. }  

如果单独调用methodB方法，则按REQUIRED属性执行。 

如果调用methodA方法，相当于下面的效果 

Java代码 

1. main(){  
2. Connection con = null;  
3. Savepoint savepoint = null;  
4. try{  
5.   con = getConnection();  
6.   con.setAutoCommit(false);  
7.   doSomeThingA();  
8.   savepoint = con2.setSavepoint();  
9.   try  
10.       methodB();  
11.   }catch(RuntimeException ex){  
12.      con.rollback(savepoint);  
13.   }  
14.   finally{  
15.     //释放资源  
16.   }  
17.   
18.   doSomeThingB();  
19.   con.commit();  
20. }  
21. catch(RuntimeException ex){  
22.   con.rollback();  
23. }  
24. finally{  
25.   //释放资源  
26. }  
27. }  

当methodB方法调用之前，调用setSavepoint方法，保存当前的状态到savepoint。如果methodB方法调用失败，则恢复到之前保存的状态。但是需要注意的是，这时的事务并没有进行提交，如果后续的代码(doSomeThingB()方法)调用失败，则回滚包括methodB方法的所有操作。 

嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。 

PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的区别:它们非常类似,都像一个嵌套事务，如果不存在一个活动的事务，都会开启一个新的事务。使用PROPAGATION_REQUIRES_NEW时，内层事务与外层事务就像两个独立的事务一样，一旦内层事务进行了提交后，外层事务不能对其进行回滚。两个事务互不影响。两个事务不是一个真正的嵌套事务。同时它需要JTA事务管理器的支持。 
使用PROPAGATION_NESTED时，外层事务的回滚可以引起内层事务的回滚。而内层事务的异常并不会导致外层事务的回滚，它是一个真正的嵌套事务。DataSourceTransactionManager使用savepoint支持PROPAGATION_NESTED时，需要JDBC 3.0以上驱动及1.4以上的JDK版本支持。其它的JTA TrasactionManager实现可能有不同的支持方式。 

PROPAGATION_REQUIRED应该是我们首先的事务传播行为。它能够满足我们大多数的事务需求。

 

 

 

 

 

 

 

 

 

spring自建事务管理模块。而且这个事务管理是一个抽象设计，可以应用到很多场合，包括普通的DataSource，jta，jms和hibernate上。 要正确使用spring的事务，首先需要了解spring在事务设计上的一些概念 统观spring事务，围绕着两个核心PlatformTransactionManager和TransactionStatus PlatformTransactionManager直译过来就是平台相关事务，这里的平台指的是“事务源”，包括刚才我说的DataSource，jta等等。这些无一不是一个事务源。广义的说，凡是可以完成事务性操作的对象，都可以设计出相对应的PlatformTransactionManager，只要这个事务源支持commit，rollback和getTransaction语意。 查看spring代码，可以发现这些manager实现事务，就是调用事务源的事务操作方法 比如 HibernateTransactionManager Java代码 protected void doCommit(DefaultTransactionStatus status); { HibernateTransactionObject txObject = (HibernateTransactionObject); status.getTransaction();; if (status.isDebug();); { logger.debug("Committing Hibernate transaction on session [" + txObject.getSessionHolder();.getSession(); + "]");; } try { txObject.getSessionHolder();.getTransaction();.commit();; } ... } jdbc 的DataSourceTransactionManager Java代码 protected void doCommit(DefaultTransactionStatus status); { DataSourceTransactionObject txObject = (DataSourceTransactionObject); status.getTransaction();; Connection con = txObject.getConnectionHolder();.getConnection();; if (status.isDebug();); { logger.debug("Committing JDBC transaction on connection [" + con + "]");; } try { con.commit();; } ... } 那么PlatformTransactionManager以什么依据处理事务呢？ 是TransactionStatus 查看api发现这个接口有三个方法 isNewTransaction() ，isRollbackOnly()，setRollbackOnly() PlatformTransactionManager就是根据前两个方法决定是否要创建一个新事务，是要递交还是回滚。至于第三个方法是改变事务当前状态的，很多地方都要用到，偏偏PlatformTransactionManager自身好像不怎么用，毕竟事务状态的改变是由程序员代码决定的，不需要一个manager多管闲事。 总结上面所说的，spring的事务由PlatformTransactionManager管理，manager最后调用事务源的方法来实现一个事务过程。而manager通过TransactionStatus 来决定如何实现。 接下去说spring事务中的TransactionTemplate和TransactionInterceptor TransactionTemplate其实和spring中其他的template的作用类似，起到化简代码的作用，不要被它那么长的名字吓倒了，事实上这个template并不是什么非常核心的对象。如果比较学究派的，可以去看看template设计模式，在此就不再对此赘述了。 为什么要有TransactionTemplate？先来看看如果没有TransactionTemplate，我们的代码该怎么写 先来看看spring reference中的一段代码 Java代码 DefaultTransactionDefinition def = new DefaultTransactionDefinition(); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);; TransactionStatus status = transactionManager.getTransaction(def);; try { // execute your business logic here } catch (MyException ex); { transactionManager.rollback(status);; throw ex; } transactionManager.commit(status);; 这是直接使用transactionManager的例子，可以看到真正执行business logic 的地方是在try当中那段，前后的代码都是为了完成事务管理的。如果每个business logic都要写上那么一段，我肯定是疯了。我们翻出TransactionTemplate的代码看看他怎么化简了我们的代码 Java代码 public Object execute(TransactionCallback action); throws TransactionException { TransactionStatus status = this.transactionManager.getTransaction(this);; Object result = null; try { result = action.doInTransaction(status);; } catch (RuntimeException ex); { // transactional code threw application exception -> rollback rollbackOnException(status, ex);; throw ex; } catch (Error err); { // transactional code threw error -> rollback rollbackOnException(status, err);; throw err; } this.transactionManager.commit(status);; return result; } 同上面的代码如出一辙，前后是事务处理代码，当中那段result = action.doInTransaction(status);是我们的应用代码。至于action是什么，全看各位的需要了。但是有一点要主要，如果利用TransactionTemplate，那么他不管你扔出什么异常都会回滚事务，但是回滚的是哪个事务呢？继续挖代码 Java代码 private void rollbackOnException(TransactionStatus status, Throwable ex); throws TransactionException { if (logger.isDebugEnabled();); { logger.debug("Initiating transaction rollback on application exception", ex);; } try { this.transactionManager.rollback(status);; } catch (RuntimeException ex2); { logger.error("Application exception overridden by rollback exception", ex);; throw ex2; } catch (Error err); { logger.error("Application exception overridden by rollback error", ex);; throw err; } } 真相大白，是对template所持有的某个transactionManager进行回滚。所以如果你的应用代码用的是事务源a的一些资源，比如到服务器a的一个datasource，但是你的transactionManager管理的是另一些资源，比如服务器b的一个datasource，代码铁定不会正常运行 特别是在一些多事务源的程序里，这点千万不能搞错。如果多个事务源之间要完成全局事务，还是老老实实用分布式事务管理服务吧（jta） 那么TransactionInterceptor是干什么的？这个是spring 的声明式事务的支持方式。因为用TransactionTemplate要硬编码，而且调整事务策略很麻烦（不是说不能调。举个例子原来程序抛出异常A需要回滚，现在不需要要，我就可以把a catch吃掉。这时候template就不会回滚了。但是每次调整都要重写编码。）而用TransactionInterceptor就可以将这些调整写在配置中。我们再来挖TransactionInterceptor的代码 Java代码 public Object invoke(MethodInvocation invocation); throws Throwable { // Work out the target class: may be null. // The TransactionAttributeSource should be passed the target class // as well as the method, which may be from an interface Class targetClass = (invocation.getThis(); != null); ? invocation.getThis();.getClass(); : null; // Create transaction if necessary TransactionInfo txInfo = createTransactionIfNecessary(invocation.getMethod();, targetClass);; Object retVal = null; try { // This is an around advice. // Invoke the next interceptor in the chain. // This will normally result in a target object being invoked. retVal = invocation.proceed();; } catch (Throwable ex); { // target invocation exception doCloseTransactionAfterThrowing(txInfo, ex);; throw ex; } finally { doFinally(txInfo);; } doCommitTransactionAfterReturning(txInfo);; return retVal; } 万变不离其宗。 所以使用spring的事务管理需要作这些事 1，设置好事务源，比如DataSource，hibernate的session。如果有多个事务源要考虑他们之间是否有全局事务，如果有，老老实实用jta，否则就需要自己写一个manager了 2，设置manager，根据你的事务源选择对应的PlatformTransactionManager 3，选择实现事物的方式，用template还是interceptor。用template代码直观点，但是template所管辖的manager和你应用代码所用的事务源要一致。如果用interceptor千万注意，一定要调用interceptor那个bean，而不是原始的那个target。在坛子上我已经看到至少有两个朋友说spring事物不起作用，从配置和代码上看都正确，这时要好好查查，调用的bean是哪一个。 4，这个是设计问题了，推荐事务处于一个较高层次，比如service上的某个函数，而底层的dao可以不考虑事务，否则可能会出现事务嵌套，增加程序复杂度。