Spring 事务管理器中传播机制属性和隔离级别

Spring 事务管理器中传播机制属性

Propagtion.Required(必须)

支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择，也是Srping默认的事务的传播

Propagtion.Supporets(支持)

支持当前事务，如果当前没有事务，就以非事务方式 执行。

Propagtion.Mandatory(强制)

使用当前的事务，如果当前没有事务，就抛出异常。

Propagtion.NOT_SUPPORTED(不支持)

以非事务方式执行，如果当前存在事务，则挂起当前事务。

Propagtion.never(从不)

以非事务方式执行，如果当前存在事务，则抛出异常。

Propagation.Nested(嵌套)

如果一个活动的事务存在，则运行在一个嵌套的事务中。如果没有活动动的事务，则按Required属性执行。它是一个单独的事务，这个事务拥有多个可以回滚的保存点，内部事务的回滚不会对外部事务造成影响。

它们非常类似,都像一个嵌套事务，如果不存在一个活动的事务，都会开启一个新的事务。
使用 PROPAGATION_REQUIRES_NEW时，内层事务与外层事务就像两个独立的事务一样，一旦内层事务进行了提交后，外层事务不能对其进行回滚。两个事务互不影响。两个事务不是一个真正的嵌套事务。同时它需要JTA事务管理器的支持。

使用PROPAGATION_NESTED时，外层事务的回滚可以引起内层事务的回滚。而内层事务的异常并不会导致外层事务的回滚，它是一个真正的嵌套事务。DataSourceTransactionManager使用savepoint支持PROPAGATION_NESTED时，需要JDBC 3.0以上驱动及1.4以上的JDK版本支持。其它的JTATrasactionManager实现可能有不同的支持方式。

• PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 “内部” 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行。

• 另一方面, PROPAGATION_NESTED 开始一个 “嵌套的” 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交。

• 由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 如果外部事务 commit, 嵌套事务也会被 commit, 这个规则同样适用于 roll back.

https://blog.youkuaiyun.com/weixin_39625809/article/details/80707695

spring事务的四种隔离级别

1、事务的四大特性（ACID）

原子性

操作要么全部成功，要么全部失败回滚。

一致性

事务执行前和执行后处于一致性状态。例如，转账前A、B共5000元，A、B之间转账后，两者之和仍应该是5000元。

隔离性

事务之间互不干扰。

持久性

事务一旦提交，数据的改变是永久性的，即使这时候数据库发生故障，数据也不会丢失。

2、与事务隔离级别的相关问题

脏读

A事务对一条记录进行修改，尚未提交，B事务已经看到了A的修改结果。若A发生回滚，B读到的数据就是错误的，这就是脏读。

不可重复读

A事务对一条记录进行修改，尚未提交，B事务第一次查询该记录，看到的是修改之后的结果，此时A发生回滚，B事务又一次查询该记录，看到的是回滚后的结果。同一个事务内，B两次查询结果不一致，这就是不可重复读。

幻读

A事务对所有记录进行修改，尚未提交，此时B事务创建了一条新记录，A、B都提交。A查看所有数据，发现有一条数据没有被修改，因为这是B事务新增的，就想看到了幻象一样，这就是幻读。

3、事务的隔离级别

读未提交（read uncommitted）

事务尚未提交，其他事务即可以看到该事务的修改结果。隔离级别最差，脏读、不可重复读、幻读都不能避免。

读提交（read committed）

事务只能看到其他事务提交之后的数据。可避免脏读，不可重复读、幻读无法避免。

不可重复读原因：A事务修改，B事务查询，A提交前和提交后，B事务看到的数据是不一致的。

幻读原因：A事务修改，B事务新增，B事务提交前，A事务已经提交。B事务提交后，A发现仍有数据未修改。

可重复读（repeatable read）-------innodb默认隔离级别

一个事务多次查询，无论其他事务对数据如何修改，看到的数据都是一致的。因为A事务查询数据时，若B同时在修改数据，A事务看到的永远是B事务执行前的数据。只有当A提交或者回滚之后，看到的才是最新的被B修改知乎的数据。可避免脏读、不可重复读，幻读无法避免。

序列化（serializable）

事务顺序执行，可避免脏读、不可重复读、幻读，但效率最差。因为A事务执行时，其他事务必须等待。