spring事物传播行为&隔离级别

Spring声明式事务

声明式事务(declarative transaction management)是Spring提供的对程序事务管理的方式之一。
Spring的声明式事务顾名思义就是采用声明的方式来处理事务。 这里所说的声明，就是指在配置文件中声明。用在Spring配置文件中声明式的处理事务来代替代码式的处理事务。这样的好处是，事务管理不侵入开发的组件，具体来说，业务逻辑对象就不会意识到正在事务管理之中，事实上也应该如此，因为事务管理是属于系统层面的服务，而不是业务逻辑的一部分，如果想要改变事务管理策划的话，也只需要在定义文件中重新配置即可；在不需要事务管理的时候，只要在设定文件上修改一下，即可移去事务管理服务，无需改变代码重新编译，这样维护起来极其方便。

事物的传播行为

Spring事务传播行为：
如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。spring特有的事务传播行为，spring支持7种事务传播行为，确定客户端和被调用端的事务边界（说得通俗一点就是多个具有事务控制的service的相互调用时所形成的复杂的事务边界控制）下图所示为7钟事务传播机制

PROPAGATION_REQUIRED（XML文件中为REQUIRED)  
表示当前方法必须在一个具有事务的上下文中运行，如有客户端有事务在进行，那么被调用端将在该事务中运行，否则的话重新开启一个事务。（如果被调用端发生异常，那么调用端和被调用端事务都将回滚）。

如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。

PROPAGATION_SUPPORTS(XML文件中为SUPPORTS）
表示当前方法不必需要具有一个事务上下文，但是如果有一个事务的话，它也可以在这个事务中运行

PROPAGATION_MANDATORY(XML文件中为MANDATORY）
表示当前方法必须在一个事务中运行，如果没有事务，将抛出异常

Spring事务传播行为：
spring特有的事务传播行为，spring支持7种事务传播行为，确定客户端和被调用端的事务边界（说得通俗一点就是多个具有事务控制的service的相互调用时所形成的复杂的事务边界控制）下图所示为7钟事务传播机制

PROPAGATION_REQUIRED（XML文件中为REQUIRED)  
表示当前方法必须在一个具有事务的上下文中运行，如有客户端有事务在进行，那么被调用端将在该事务中运行，否则的话重新开启一个事务。（如果被调用端发生异常，那么调用端和被调用端事务都将回滚）。
如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。


PROPAGATION_SUPPORTS(XML文件中为SUPPORTS）
表示当前方法不必需要具有一个事务上下文，但是如果有一个事务的话，它也可以在这个事务中运行。
支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。‘


PROPAGATION_MANDATORY(XML文件中为MANDATORY）
表示当前方法必须在一个事务中运行，如果没有事务，将抛出异常。
支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。


PROPAGATION_NESTED(XML文件中为NESTED)
表示如果当前方法正有一个事务在运行中，则该方法应该运行在一个嵌套事务中，被嵌套的事务可以独立于被封装的事务中进行提交或者回滚。如果封装事务存在，并且外层事务抛出异常回滚，那么内层事务必须回滚，反之，内层事务并不影响外层事务。如果封装事务不存在，则同PROPAGATION_REQUIRED的一样

PROPAGATION_NEVER（XML文件中为NEVER)
表示当方法务不应该在一个事务中运行，如果存在一个事务，则抛出异常

PROPAGATION_REQUIRES_NEW(XML文件中为REQUIRES_NEW）
表示当前方法必须运行在它自己的事务中。一个新的事务将启动，而且如果有一个现有的事务在运行的话，则这个方法将在运行期被挂起，直到新的事务提交或者回滚才恢复执行。

PROPAGATION_NOT_SUPPORTED（XML文件中为NOT_SUPPORTED）
表示该方法不应该在一个事务中运行。如果有一个事务正在运行，他将在运行期被挂起，直到这个事务提交或者回滚才恢复执行

http://blog.csdn.net/pml18710973036/article/details/58607148

http://blog.csdn.net/hsgao_water/article/details/52860380

Spring的隔离级别

声明式事务的第二个方面是隔离级别。隔离级别定义一个事务可能受其他并发事务活动活动影响的程度。另一种考虑一个事务的隔离级别的方式，是把它想象为那个事务对于事物处理数据的自私程度。
在一个典型的应用程序中，多个事务同时运行，经常会为了完成他们的工作而操作同一个数据。并发虽然是必需的，但是会导致以下问题：
丢失更新
当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。 　　
例:
事务A和事务B同时修改某行的值，
1.事务A将数值改为1并提交
2.事务B将数值改为2并提交。
这时数据的值为2，事务A所做的更新将会丢失。 
解决办法：对行加锁，只允许并发一个更新事务。
脏读
一个事务读到另一个事务未提交的更新数据
例:
1.Mary的原工资为1000, 财务人员将Mary的工资改为了8000(但未提交事务)         
2.Mary读取自己的工资 ,发现自己的工资变为了8000，欢天喜地！
3.而财务发现操作有误，回滚了事务,Mary的工资又变为了1000, 像这样,Mary记取的工资数8000是一个脏数据。
不可重复读
在同一个事务中,多次读取同一数据,返回的结果有所不同. 换句话说就是,后续读取可以读到另一个事务已提交的更新数据. 相反"可重复读"在同一事务多次读取数据时,能够保证所读数据一样,也就是后续读取不能读到另一事务已提交的更新数据.
例:
1.在事务1中，Mary 读取了自己的工资为1000,操作并没有完成
2.在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务.
3.在事务1中，Mary 再次读取自己的工资时，工资变为了2000
解决办法：如果只有在修改事务完全提交之后才可以读取数据，则可以避免该问题。
幻读
一个事务读取到另一个事务已提交的insert数据.
例:
第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时 (此时第一事务还未提交) ，第二个事务向表中插入一行新数据。这时第一个事务再去读取表时,发现表中还有没有修改的数据行，就好象发生了幻觉一样。
在理想状态下，事务之间将完全隔离，从而可以防止这些问题发生。然而，完全隔离会影响性能，因为隔离经常牵扯到锁定在数据库中的记录（而且有时是锁定完整的数据表）。侵占性的锁定会阻碍并发，要求事务相互等待来完成工作。
考虑到完全隔离会影响性能，而且并不是所有应用程序都要求完全隔离，所以有时可以在事务隔离方面灵活处理。因此，就会有好几个隔离级别。
在理想状态下，事务之间将完全隔离，从而可以防止这些问题发生。然而，完全隔离会影响性能，因为隔离经常牵扯到锁定在数据库中的记录（而且有时是锁定完整的数据表）。侵占性的锁定会阻碍并发，要求事务相互等待来完成工作。
考虑到完全隔离会影响性能，而且并不是所有应用程序都要求完全隔离，所以有时可以在事务隔离方面灵活处理。因此，就会有好几个隔离级别。
隔离级别
 1. ISOLATION_DEFAULT： 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别。
 另外四个与JDBC的隔离级别相对应
 2. ISOLATION_READ_UNCOMMITTED： 这是事务最低的隔离级别，它充许另外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻读。
 3. ISOLATION_READ_COMMITTED： 允许从已经提交的并发事务读取。可防止脏读，但幻影读和不可重复读仍可能会发生。保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。
 4. ISOLATION_REPEATABLE_READ： 对相同字段的多次读取的结果是一致的，除非数据被当前事务本身改变。可防止脏读和不可重复读，但幻影读仍可能发生。这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。
      它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
 5. ISOLATION_SERIALIZABLE 完全服从ACID的隔离级别，确保不发生脏读、不可重复读和幻影读。这在所有隔离级别中也是最慢的，因为它通常是通过完全锁定当前事务所涉及的数据表来完成的。这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。