Spring事物管理——属性分析

一、事务隔离级别

隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量：

名称	含义
ISOLATION_DEFAULT	这是默认值，表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是ISOLATION_READ_COMMITTED。
ISOLATION_READ_UNCOMMITTED	该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读和不可重复读，因此很少使用该隔离级别。
ISOLATION_READ_COMMITTED	该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，但是可能会出现不可重复读和幻像读。 这也是大多数情况下的推荐值。
ISOLATION_REPEATABLE_READ	该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。即使在多次查询之间有新增的数据满足该查询，这些新增的记录也会被忽略。该级别可以防止脏读和不可重复读。
ISOLATION_SERIALIZABLE	所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

什么是脏数据，脏读，不可重复读，幻觉读？　　

　　脏读: 指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。

例如: Mary的原工资为1000,财务人员将Mary的工资改为了8000，但未提交事务 

Java代码：
Connection con1 = getConnection();  
con.setAutoCommit(false);  
update employee set salary = 8000 where empId ="Mary";  


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

Java代码：
Connection con2 = getConnection();  
select  salary from employee where empId ="Mary";  
con2.commit();  

Mary发现自己的工资变为了8000，欢天喜地！ 

而财务发现操作有误，而回滚了事务,Mary的工资又变为了1000 

Java代码：
//con1  
con1.rollback();  

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

　　不可重复读: 指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。 那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。

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

Java代码：
con1 = getConnection();  
select salary from employee empId ="Mary";  

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

Java代码：
con2 = getConnection();  
update employee set salary = 2000;  
con2.commit();  

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

Java代码：
//con1  
select salary from employee empId ="Mary";  

在一个事务中前后两次读取的结果并不致，导致了不可重复读。 

　　幻觉读: 指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

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

Java代码：
con1 = getConnection();  
Select * from employee where salary =1000;  

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

Java代码：
con2 = getConnection();  
Insert into employee(empId,salary) values("Lili",1000);  
con2.commit();  

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

Java代码：
//con1  
select * from employee where salary =1000;  

共读取到了11条记录，这就产生了幻像读。 

　　不可重复读与幻觉读区别：幻觉读与不可重复读有点相似，但是不可重复读读取的数据不一致是因为他所要取的数据集被改变了。但是phantom reads所要读的数据的不一致却不是他所要读的数据集改变，而是他的条件数据集改变。比如Select account.id where account.name=”ppgogo*”,第一次读去了6个符合条件的id，第二次读取的时候，由于事务b把一个帐号的名字由”dd”改成”ppgogo1”，结果取出来了7个数据。

---

二、事务传播行为

所谓事务的传播行为是指，如果在开始当前事务之前，一个事务上下文已经存在，此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量：

名称	含义
PROPAGATION_REQUIRED	如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
PROPAGATION_REQUIRES_NEW	创建一个新的事务，如果当前存在事务，则把当前事务挂起。
PROPAGATION_SUPPORTS	如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
PROPAGATION_NOT_SUPPORTED	以非事务方式运行，如果当前存在事务，则把当前事务挂起。
PROPAGATION_NEVER	以非事务方式运行，如果当前存在事务，则抛出异常。
PROPAGATION_MANDATORY	如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
PROPAGATION_NESTED	如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于PROPAGATION_REQUIRED。

事务的嵌套

假设外层事务 Service A 的 Method A() 调用 内层Service B 的 Method B()

1、PROPAGATION_REQUIRED(spring 默认)

如果ServiceB.methodB() 的事务级别定义为 PROPAGATION_REQUIRED，那么执行 ServiceA.methodA() 的时候spring已经起了事务，这时调用 ServiceB.methodB()，ServiceB.methodB() 看到自己已经运行在 ServiceA.methodA() 的事务内部，就不再起新的事务。
假如 ServiceB.methodB() 运行的时候发现自己没有在事务中，他就会为自己分配一个事务。
这样，在 ServiceA.methodA() 或者在 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() 事务仍然可能提交(主要看B抛出的异常是不是A会回滚的异常)。

3、PROPAGATION_SUPPORTS

假设ServiceB.methodB() 的事务级别为 PROPAGATION_SUPPORTS，那么当执行到ServiceB.methodB()时，如果发现ServiceA.methodA()已经开启了一个事务，则加入当前的事务，如果发现ServiceA.methodA()没有开启事务，则自己也不开启事务。这种时候，内部方法的事务性完全依赖于最外层的事务。

4、PROPAGATION_NESTED
ServiceB.methodB() 的事务属性被配置为 PROPAGATION_NESTED, 此时两者之间又将如何协作呢? 


//事务属性 PROPAGATION_REQUIRED   
methodA(){  
    doSomeThingA();  
    methodB();  
    doSomeThingB();  
}  

//事务属性 PROPAGATION_NESTED  
methodB(){  
    ……  
}  

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

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

main(){  
    Connection con = null;  
    Savepoint savepoint = null;  
    try{  
        con = getConnection();  
        con.setAutoCommit(false);  
        doSomeThingA();  
        savepoint = con2.setSavepoint();  
        try{ 
            methodB();  
        }catch(RuntimeException ex){  
            con.rollback(savepoint);  
        }  
        finally{  
            //释放资源  
        }  
        doSomeThingB();  
        con.commit();  
    }  
    catch(RuntimeException ex){  
        con.rollback();  
    }  
    finally{  
        //释放资源  
    }
}  

当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实现可能有不同的支持方式。

转载： http://blog.csdn.net/hjm4702192/article/details/17277669
http://www.codeceo.com/article/spring-transactions.html