Spring事务

Spring事务

编程式事务：在代码中硬编码(在分布式系统中推荐使用) : 通过 TransactionTemplate或者 TransactionManager 手动管理事务，事务范围过大会出现事务未提交导致超时，因此事务要比锁的粒度更小。

事务简介

原子性，一致性，事务隔离，持久性

事务在逻辑上是一组操作，要么执行，要不都不执行。主要是针对数据库而言的，比如说 MySQL。
为了保证事务是正确可靠的，在数据库进行写入或者更新操作时，就必须得表现出 ACID 的 4 个重要特性：

  • 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
  • 一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。
  • 事务隔离（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
  • 持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失

其中，事务隔离又分为 4 种不同的级别，包括：

默认：可重复读（repeatable read）

  • 未提交读（Read uncommitted），最低的隔离级别，允许“脏读”（dirty reads），事务可以看到其他事务“尚未提交”的修改。如果另一个事务回滚，那么当前事务读到的数据就是脏数据。
  • 提交读（read committed），一个事务可能会遇到不可重复读（Non Repeatable Read）的问题。不可重复读是指，在一个事务内，多次读同一数据，在这个事务还没有结束时，如果另一个事务恰好修改了这个数据，那么，在第一个事务中，两次读取的数据就可能不一致。
  • 可重复读（repeatable read），一个事务可能会遇到幻读（Phantom Read）的问题。幻读是指，在一个事务中，第一次查询某条记录，发现没有，但是，当试图更新这条不存在的记录时，竟然能成功，并且，再次读取同一条记录，它就神奇地出现了。
  • 串行化（Serializable），最严格的隔离级别，所有事务按照次序依次执行，因此，脏读、不可重复读、幻读都不会出现。虽然 Serializable 隔离级别下的事务具有最高的安全性，但是，由于事务是串行执行，所以效率会大大下降，应用程序的性能会急剧降低。如果没有特别重要的情景，一般都不会使用 Serializable 隔离级别。

事务传播

1.PROPAGATION_REQUIRED

这也是 @Transactional 默认的事务传播行为，指的是如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。更确切地意思是：
如果外部方法没有开启事务的话，Propagation.REQUIRED 修饰的内部方法会开启自己的事务，且开启的事务相互独立，互不干扰。
如果外部方法开启事务并且是 Propagation.REQUIRED 的话，所有 Propagation.REQUIRED 修饰的内部方法和外部方法均属于同一事务 ，只要一个方法回滚，整个事务都需要回滚。

也就是说如果a方法和b方法都添加了注解，在默认传播模式下，a方法内部调用b方法，会把两个方法的事务合并为一个事务。

  1. PROPAGATION_REQUIRES_NEW

创建一个新的事务，如果当前存在事务，则把当前事务挂起。也就是说不管外部方法是否开启事务，Propagation.REQUIRES_NEW 修饰的内部方法都会开启自己的事务，且开启的事务与外部的事务相互独立，互不干扰。

当类A中的 a 方法用默认 Propagation.REQUIRED模式，类B中的 b方法加上采用 Propagation.REQUIRES_NEW模式，然后在 a 方法中调用 b方法操作数据库，然而 a方法抛出异常后，b方法并没有进行回滚，因为Propagation.REQUIRES_NEW会暂停 a方法的事务 ，总结就是a不影响b，b影响a

  1. PROPAGATION_NESTED

无非就相当于加入了事务，但是他是开启的一个事务，两个事务同时成功、同时失败！

如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

关于回滚：

两个事务（外部和内部）的失败回滚行为并不是完全独立的。如果内部事务失败并回滚，那么它所做的更改会被撤销，但这不会直接触发外部事务的回滚。然而，如果外部事务因为某种原因（例如遇到异常）而决定回滚，那么内部事务的所有更改也会被撤销，因为内部事务是外部事务的一部分。

简而言之，PROPAGATION_NESTED 的主要特点是：

  • 如果外部事务提交，那么内部事务的提交状态将决定其是否真正提交。
  • 如果外部事务回滚，那么内部事务的所有更改都会被撤销，不论其自身的提交状态如何。
  1. PROPAGATION_MANDATORY

如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。（mandatory：强制性）这个使用的很少。

事务隔离

TransactionDefinition 中一共定义了 5 种事务隔离级别：

可重复读（默认）、未提交读、提交读、串行化

  • ISOLATION_DEFAULT，使用数据库默认的隔离级别，MySql 默认采用的是 REPEATABLE_READ，也就是可重复读。

这个隔离级别保证在同一个事务中多次读取同样记录的结果是一致的。但是，在可重复读隔离级别下，其他事务可以修改这些记录，只是这些修改对于当前事务是不可见的（会产生并发安全问题，可以使用悲观锁解决）

实现原理：它通常依赖于数据库的多版本并发控制（MVCC）机制。在MVCC中，每个事务在开始时都会获得一个唯一的版本号，并且每次数据修改时，都会生成一个新的数据版本，这个版本与修改它的事务的版本号相关联。这样，当其他事务尝试读取数据时，它会根据当前事务的版本号来查找对应的数据版本，确保读取到的是事务开始时的数据状态。

  • ISOLATION_READ_UNCOMMITTED，最低的隔离级别，可能会出现脏读、幻读或者不可重复读。
  • ISOLATION_READ_COMMITTED，允许读取并发事务提交的数据，可以防止脏读，但幻读和不可重复读仍然有可能发生。
  • ISOLATION_REPEATABLE_READ，对同一字段的多次读取结果都是一致的，除非数据是被自身事务所修改的，可以阻止脏读和不可重复读，但幻读仍有可能发生。
  • ISOLATION_SERIALIZABLE，最高的隔离级别，虽然可以阻止脏读、幻读和不可重复读，但会严重影响程序性能。

  1. 事务的超时时间

    事务超时**timeout **，也就是指一个事务所允许执行的最长时间，如果在超时时间内还没有完成的话，就自动回滚。
    假如事务的执行时间格外的长，由于事务涉及到对数据库的锁定，就会导致长时间运行的事务占用数据库资源。

  2. 事务的只读属性
    事务的只读属性readOnly， 如果一个事务只是对数据库执行读操作，那么该数据库就可以利用事务的只读属性，采取优化措施，适用于多条数据库查询操作中。
    为什么一个查询操作还要启用事务支持呢？
    这是因为 MySql（innodb）默认对每一个连接都启用了 autocommit 模式，在该模式下，每一个发送到 MySql 服务器的 SQL 语句都会在一个单独的事务中进行处理，执行结束后会自动提交事务。
    那如果我们给方法加上了 @Transactional 注解，那这个方法中所有的 SQL 都会放在一个事务里。否则，每条 SQL 都会单独开启一个事务，中间被其他事务修改了数据，都会实时读取到。
    有些情况下，当一次执行多条查询语句时，需要保证数据一致性时，就需要启用事务支持。否则上一条 SQL 查询后，被其他用户改变了数据，那么下一个 SQL 查询可能就会出现不一致的状态。

  3. 事务的回滚策略
    **回滚策略rollbackFor **，用于指定能够触发事务回滚的异常类型，可以指定多个异常类型。默认情况下，事务只在出现运行时异常（Runtime Exception）时回滚，以及 Error，出现检查异常（checked exception，需要主动捕获处理或者向上抛出）时不回滚。如果你想要回滚特定的异常类型的话，可以这样设置：@Transactional(rollbackFor= MyException.class)

  4. 事务的不回滚策略
    **不回滚策略noRollbackFor **，用于指定不触发事务回滚的异常类型，可以指定多个异常类型。

@Transactional事务原理

Spring - Understanding the correct use of @Transactional (logicbig.com)

本质基于AOP的代理，在service方法内部方法调用事务方法AOP无法拦截，这就导致了事务失效，

而通过注入Bean去调用事务方法则能生效