Spring（1） 事务处理学习

Spring事务目前我主要了解两个内容： 

1、Spring 事务的隔离性。

2、Spring 事务的传播行为。

首先，事务的隔离性主要是对于事务可能出现的：脏读、幻读、 不可重复读 等问题的解决。

   事务隔离级别的写法：

在事务的隔离级别中， 存在5中级别:分别是default ， read_Uncommited ,read_commited , REPEATABLE_READ 和 SERIALIZABLE。 其中，default 为默认， 默认的结果就是和数据库一致，如果数据库支持事务，那就是用数据库默认的隔离级别。其对应可能存在的问题如下：

毫无疑问，隔离等级越高， 对应的资源消耗也就越严重。所以，在事务的隔离级别中，我们需要通过自己对于程序安全性的判断， 在保证程序安全的情况下，选择最优的级别。

 

然后，是关于事务的传播行为：

  在Spring 事务中存在7中传播行为。

1） PROPAGATION_REQUIRED ，默认的spring事务传播级别，使用该级别的特点是，如果上下文中已经存在事务，那么就加入到事务中执行，如果当前上下文中不存在事务，则新建事务执行。所以这个级别通常能满足处理大多数的业务场景。

2）PROPAGATION_SUPPORTS ，从字面意思就知道，supports，支持，该传播级别的特点是，如果上下文存在事务，则支持事务加入事务，如果没有事务，则使用非事务的方式执行。所以说，并非所有的包在transactionTemplate.execute中的代码都会有事务支持。这个通常是用来处理那些并非原子性的非核心业务逻辑操作。应用场景较少。

3）PROPAGATION_MANDATORY ， 该级别的事务要求上下文中必须要存在事务，否则就会抛出异常！配置该方式的传播级别是有效的控制上下文调用代码遗漏添加事务控制的保证手段。比如一段代码不能单独被调用执行，但是一旦被调用，就必须有事务包含的情况，就可以使用这个传播级别。

4）PROPAGATION_REQUIRES_NEW ，从字面即可知道，new，每次都要一个新事务，该传播级别的特点是，每次都会新建一个事务，并且同时将上下文中的事务挂起，执行当前新建事务完成以后，上下文事务恢复再执行。

这是一个很有用的传播级别，举一个应用场景：现在有一个发送100个红包的操作，在发送之前，要做一些系统的初始化、验证、数据记录操作，然后发送100封红包，然后再记录发送日志，发送日志要求100%的准确，如果日志不准确，那么整个父事务逻辑需要回滚。
怎么处理整个业务需求呢？就是通过这个PROPAGATION_REQUIRES_NEW 级别的事务传播控制就可以完成。发送红包的子事务不会直接影响到父事务的提交和回滚。

5）PROPAGATION_NOT_SUPPORTED ，这个也可以从字面得知，not supported ，不支持，当前级别的特点就是上下文中存在事务，则挂起事务，执行当前逻辑，结束后恢复上下文的事务。

这个级别有什么好处？可以帮助你将事务极可能的缩小。我们知道一个事务越大，它存在的风险也就越多。所以在处理事务的过程中，要保证尽可能的缩小范围。比如一段代码，是每次逻辑操作都必须调用的，比如循环1000次的某个非核心业务逻辑操作。这样的代码如果包在事务中，势必造成事务太大，导致出现一些难以考虑周全的异常情况。所以这个事务这个级别的传播级别就派上用场了。用当前级别的事务模板抱起来就可以了。

6）PROPAGATION_NEVER ，该事务更严格，上面一个事务传播级别只是不支持而已，有事务就挂起，而PROPAGATION_NEVER传播级别要求上下文中不能存在事务，一旦有事务，就抛出runtime异常，强制停止执行！这个级别上辈子跟事务有仇。

7）PROPAGATION_NESTED ，字面也可知道，nested，嵌套级别事务。该传播级别特征是，如果上下文中存在事务，则嵌套事务执行，如果不存在事务，则新建事务。

这里主要介绍REQUIRED，REQUIRED_NEW，NESTED 。

REQUIRED ： 再开启事务的情况下，下级事务默认加入上级事务。且任意一级事务出现错误，整体都要回滚。

REQUIRED_NEW ： 该事务行为为创建新的事务， 如果上级事务调用该事务， 那么该事务创建新事务， 与上级事务相互隔离，互不影响。当前事务执行失败， 上级事务任可继续执行， 反之同理。

NESTED  ： 该事务为嵌套事务， 即嵌套在上级事务中， 依赖上级，如果上级回滚， 则当前事务回滚。 但无法影响上级，当前事务回滚，上级任可继续执行。

 

详细解读：https://blog.csdn.net/u010963948/article/details/82761383