spring事务传播属性和隔离级别

1 事务的传播属性（Propagation） 

1) REQUIRED ，这个是默认的属性 
Support a current transaction, create a new one if none exists. 
若是存在一个事务，则支持当前事务。若是没有事务则开启一个新的事务。 
被设置成这个级别时，会为每个被调用的方法建立一个逻辑事务域。若是前面的方法已经建立了事务，那么后面的方法支持当前的事务，若是当前没有事务会从新创建事务。 
如图所示： 

2) MANDATORY 
Support a current transaction, throw an exception if none exists.支持当前事务，若是当前没有事务，就抛出异常。 

3) NEVER 
Execute non-transactionally, throw an exception if a transaction exists. 
以非事务方式执行，若是当前存在事务，则抛出异常。 

4) NOT_SUPPORTED 
Execute non-transactionally, suspend the current transaction if one exists. 
以非事务方式执行操做，若是当前存在事务，就把当前事务挂起。 

5) REQUIRES_NEW 
Create a new transaction, suspend the current transaction if one exists. 
新建事务，若是当前存在事务，把当前事务挂起。 
如图所示： 

6) SUPPORTS 
Support a current transaction, execute non-transactionally if none exists. 
支持当前事务，若是当前没有事务，就以非事务方式执行。 

7) NESTED 
Execute within a nested transaction if a current transaction exists, behave like PROPAGATION_REQUIRED else. 
支持当前事务，新增Savepoint点，与当前事务同步提交或回滚。 
嵌套事务一个很是重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所作的动做。而内层事务操做失败并不会引发外层事务的回滚。 

8) PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的区别 
它们很是 相似,都像一个嵌套事务，若是不存在一个活动的事务，都会开启一个新的事务。使用PROPAGATION_REQUIRES_NEW时，内层事务与外层事务就像两个独立的事务同样，一旦内层事务进行了提交后，外层事务不能对其进行回滚。两个事务互不影响。两个事务不是一个真正的嵌套事务。同时它须要JTA 事务管理器的支持。 
使用PROPAGATION_NESTED时，外层事务的回滚能够引发内层事务的回滚。而内层事务的异常并不会致使外层事务的回滚，它是一个真正的嵌套事务。 

2 事务的隔离级别（Isolation Level） 

1) 首先说明一下事务并发引发的三种状况 

i. Dirty Reads 脏读 
一个事务正在对数据进行更新操做，可是更新还未提交，另外一个事务这时也来操做这组数据，而且读取了前一个事务还未提交的数据，而前一个事务若是操做失败进行了回滚，后一个事务读取的就是错误数据，这样就形成了脏读。

ii. Non-Repeatable Reads 不可重复读 
一个事务屡次读取同一数据，在该事务还未结束时，另外一个事务也对该数据进行了操做，并且在第一个事务两次次读取之间，第二个事务对数据进行了更新，那么第一个事务先后两次读取到的数据是不一样的，这样就形成了不可重复读。

iii. Phantom Reads 幻像读 
第一个数据正在查询符合某一条件的数据，这时，另外一个事务又插入了一条符合条件的数据，第一个事务在第二次查询符合同一条件的数据时，发现多了一条前一次查询时没有的数据，仿佛幻觉同样，这就是幻像读。

iv. 非重复度和幻像读的区别 
非重复读是指同一查询在同一事务中屡次进行，因为其余提交事务所作的修改或删除，每次返回不一样的结果集，此时发生非重复读。(A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data. )

幻像读是指同一查询在同一事务中屡次进行，因为其余提交事务所作的插入操做，每次返回不一样的结果集，此时发生幻像读。(A transaction reexecutes a query returning a set of rows that satisfies a search condition and finds that another committed transaction has inserted additional rows that satisfy the condition. )

表面上看，区别就在于非重复读能看见其余事务提交的修改和删除，而幻像能看见其余事务提交的插入。 

2) DEFAULT （默认） 
这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.另外四个与JDBC的隔离级别相对应 

3) READ_UNCOMMITTED （读未提交） 
这是事务最低的隔离级别，它容许另一个事务能够看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。 

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

5) REPEATABLE_READ （可重复读） 
这种事务隔离级别能够防止脏读，不可重复读。可是可能出现幻像读。它除了保证一个事务不能读取另外一个事务未提交的数据外，还保证了不可重复读 

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

7) 隔离级别解决事务并行引发的问题 
Dirty reads non-repeatable reads phantom reads 
Serializable 不会 不会 不会 
REPEATABLE READ 不会 不会 会 
READ COMMITTED 不会 会 会 
Read Uncommitted 会 会 会

 

事物传播行为介绍: 
@Transactional(propagation=Propagation.REQUIRED) 
若是有事务, 那么加入事务, 没有的话新建一个(默认状况下)
@Transactional(propagation=Propagation.NOT_SUPPORTED) 
容器不为这个方法开启事务
@Transactional(propagation=Propagation.REQUIRES_NEW) 
不论是否存在事务,都建立一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务
@Transactional(propagation=Propagation.MANDATORY) 
必须在一个已有的事务中执行,不然抛出异常
@Transactional(propagation=Propagation.NEVER) 
必须在一个没有的事务中执行,不然抛出异常(与Propagation.MANDATORY相反)
@Transactional(propagation=Propagation.SUPPORTS) 
若是其余bean调用这个方法,在其余bean中声明事务,那就用事务.若是其余bean没有声明事务,那就不用事务.

事物超时设置:
@Transactional(timeout=30) //默认是30秒

事务隔离级别:
@Transactional(isolation = Isolation.READ_UNCOMMITTED)
读取未提交数据(会出现脏读, 不可重复读) 基本不使用
@Transactional(isolation = Isolation.READ_COMMITTED)
读取已提交数据(会出现不可重复读和幻读)
@Transactional(isolation = Isolation.REPEATABLE_READ)
可重复读(会出现幻读)
@Transactional(isolation = Isolation.SERIALIZABLE)
串行化

MYSQL: 默认为REPEATABLE_READ级别
SQLSERVER: 默认为READ_COMMITTED

脏读 : 一个事务读取到另外一事务未提交的更新数据
不可重复读 : 在同一事务中, 屡次读取同一数据返回的结果有所不一样, 换句话说, 
后续读取能够读到另外一事务已提交的更新数据. 相反, "可重复读"在同一事务中屡次
读取数据时, 可以保证所读数据同样, 也就是后续读取不能读到另外一事务已提交的更新数据
幻读 : 一个事务读到另外一个事务已提交的insert数据

 关于嵌套事物   可能你们对PROPAGATION_NESTED还不怎么了解，以为有必要再补充一下^_^！ PROPAGATION_NESTED: 嵌套事务类型，是相对上面提到的六种状况（上面的六种应该称为平面事务类型），打个比方我如今有一个事务主要有一下几部分：       1，从A用户账户里面减去100元钱       2，往B用户账户里面添加100元钱        这样看和之前不一样的事务可能没有什么区别，那我如今有点特殊的要求就是，A用户有3个账户，B用户有2个账户，如今个人要求就是只要再A用户的3个账户里面任意一个减去100元，往B用户的两个账户中任意一个里面增长100元就能够了！        一旦你有这样的要求那嵌套事务类型就很是适合你！咱们能够这样理解，        一：将“从A用户账户里面减去100元钱” 和 “往B用户账户里面增长100元钱”咱们暂时认为是一级事务操做        二：将从A用户的3个账户的任意一个账户里面减钱看作是“从A用户账户里面减去100元钱”这个一级事务的子事务（二级事务），一样把后面存钱的当作是另外一个的二级事务。       问题一：当二级事务被rollback一级事务会不会被rollback？       答案是不会的，二级事务的rollback只针对本身。       问题二：何时这个一级事务会commit，何时会被rollback呢？       咱们主要看二级里面出现的状况，当全部的二级事务被commit了而且一级事务没有失败的操做，那整个事务就算是一个成功的事务，这种状况整个事务会被commit。 当任意一个二级事务没有被commit那整个事务就是失败的，整个事务会被roolback。 仍是拿上面的例子来讲明吧！若是我在a的三个账户里面减钱的操做都被二级事务给rollback了，也就是3个账户里面都没有减钱成功，整个事务就失败了就会被rollback。若是A用户账户三个账户里面有一个能够扣钱并且B用户的两个账户里面也有一个账户能够增长钱，那整个事务就算成功的，会被 commit。 看了一下以为上面的例子好像不是很深入，看这个状况（A用户的3个账户都是有信用额度的，也就是说能够超支，可是超支有金额限制）。不过原理是同样的，简单点也好说明一点，祝你好运！^_^