spring 事务管理的例子

最近做项目时发现以前批量提交到数据库的数据有一小部分没提交成功，不完整的数据导致业务系统出现异常。我体会到了事务的重要性，看spring对事务的介绍一直不太懂，现在正好借机研究一下。

理论性的介绍很容易找到，可以参考 http://fhjxp.iteye.com/blog/124978 。可贵的是该链接也有例子解释概念。个人总结要点：

********************sample***********************
ServiceA {   
       
     /**  
      * 事务属性配置为 PROPAGATION_REQUIRED  
      */  
     void methodA() {   
         ServiceB.methodB();   
     }   
  
}   
  
ServiceB {   
       
     /**  
      * 事务属性配置为 PROPAGATION_REQUIRED  
      */    
     void methodB() {   
     }   
       
}      

*************************************************
我们这里一个个分析吧
1： PROPAGATION_REQUIRED
加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务
比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，
         ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA
的事务内部，就不再起新的事务。而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。
这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。即使ServiceB.methodB的事务已经被
提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚

2：   PROPAGATION_REQUIRES_NEW
这个就比较绕口了。 比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW，
那么当执行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起，ServiceB.methodB会起一个新的事务，等待ServiceB.methodB的事务完成以后，
他才继续执行。他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为ServiceB.methodB是新起一个事务，那么就是存在
两个不同的事务。如果ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚，ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚，
如果他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。

3：PROPAGATION_NESTED
理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，将会与他的父事务相互独立，
而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。
而Nested事务的好处是他有一个savepoint。
*****************************************
ServiceA {   
       
     /**  
      * 事务属性配置为 PROPAGATION_REQUIRED  
      */  
     void methodA() {   
         try {
      //savepoint   
             ServiceB.methodB();    //PROPAGATION_NESTED 级别
         } catch (SomeException) {   
             // 执行其他业务, 如 ServiceC.methodC();   
         }   
     }   
  
}   
********************************************
也就是说ServiceB.methodB失败回滚，那么ServiceA.methodA也会回滚到savepoint点上，ServiceA.methodA可以选择另外一个分支，比如
ServiceC.methodC，继续执行，来尝试完成自己的事务。

====================================================================================================

http://osacar.iteye.com/blog/1331170点击打开链接 很精彩：要点如下

在执行读取操作时，避免使用 @Transactional 注释

运行时异常（即非受控异常）自动强制执行整个逻辑工作单元的回滚，但受控异常不会。如下例：

1. @Transactional(propagation=Propagation.REQUIRED)     
2. public TradeData placeTrade(TradeData trade) throws Exception {     
3.    try {     
4.       insertTrade(trade);     
5.       updateAcct(trade);     
6.       return trade;     
7.    } catch (Exception up) {     
8.       //log the error     
9.       throw up;     
10.    }     
11. }   

假设帐户中没有足够的资金来购买需要的股票，或者还没有准备购买或出售股票，并抛出了一个受控异常（例如 FundsNotAvailableException），那么交易订单会保存在数据库中吗？还是整个逻辑工作单元将执行回滚？答案出乎意料：根据受控异 常（不管是在 Spring Framework 中还是在 EJB 中），事务会提交它还未提交的所有工作。使用清单 13，这意味着，如果在执行 updateAcct() 方法期间抛出受控异常，就会保存交易订单，但不会更新帐户来反映交易情况。

=========================================

http://blog.chinaunix.net/uid-29234606-id-3977632.html 或 http://blog.csdn.net/liovey/article/details/14149137 简明的例子。两个一样，不知道谁抄袭谁

============================================

http://my.oschina.net/u/1166271/blog/199546点击打开链接 系列文章很系统，可是有些链接打不开了。