SpringBoot容器事务学习

Spring容器事务

由于在实际开发过程中，我们大多利用@transactional注解来进行事务开发，因此我们通过分析@Transactional注解来简单介绍Spring事务。（如果有错误，欢迎指正）

在正文开启之前，必须要重申一个观点-那就是——所有的事务，都应该从实际业务出发，通过你对这个分析来对事务的各个属性进行配置，比如事务的传播方式及隔离级别

事务的四个特征

虽然是大家都懂的几个特征，但是还是需要强调。

• 原子性（Atomicity）： 事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用。
• 一致性（Consistency）：一旦事务完成（不管成功还是失败），系统必须确保它所建模的业务处于一致的状态，而不会是部分完成部分失败。在现实中的数据不应该被破坏。
• 隔离性（Isolation）：可能有许多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。
• 持久性（Durability）：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，这样就能从任何系统崩溃中恢复过来。通常情况下，事务的结果被写到持久化存储器中。

核心Api

大体逻辑

DefaultTransactionDefinition def = new DefaultTransactionDefinition();

PlatformTransactionManager txManager = new DataSourceTransactionManager(dataSource);

TransactionStatus status = txManager.getTransaction(def);

try {

 //get jdbc connection...

 //execute sql...

}

catch (Exception e) {

 txManager.rollback(status);

 throw e;

}

txManager.commit(status);

其实事务未提交时，数据已经写入内存甚至磁盘了，但是由于为了防止（脏读，幻读不可重复读等），因此其他线程（事务）**默认**无法访问本事务未提交的数据（MYSQL 默认-可重复读）

Transactional注解

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {
    @AliasFor("transactionManager")
    String value() default "";

    @AliasFor("value")
    String transactionManager() default "";

    Propagation propagation() default Propagation.REQUIRED;

    Isolation isolation() default Isolation.DEFAULT;

    int timeout() default -1;

    boolean readOnly() default false;

    Class<? extends Throwable>[] rollbackFor() default {};

    String[] rollbackForClassName() default {};

    Class<? extends Throwable>[] noRollbackFor() default {};

    String[] noRollbackForClassName() default {};
}

1. value / transactionManager字段

由于添加了@AliasFor注解，因此value和transactionManager互为别名，他的作用是指定事务所属的事务管理器

2.ReadOnly 只读事务

从这一点设置的时间点开始（时间点a）到这个事务结束的过程中，其他事务所提交的数据，该事务将看不见！（查询中不会出现别人在时间点a之后提交的数据。

3. timeout 事务超时

超时时间，单位为s，deadline = 事务开启的时间 + 最后一次statement执行的结束时间，即如果当前事务方法总执行时间为10s,查库是5s，后面还有一个5s的sleep，timeout=6，该次事务将不会超时。

值得注意的是，在我们SpringBoot集成MyBatis的环境中，该属性只在利用jdbcTemplate执行Sql时生效，利用Mapper查询不生效（本人经过测试证实这一观点），原因在于Spring源码，详情可以看这篇文章的分析

4.事务的隔离级别

需要注意的是，隔离级别是指两两事务之间的
MYSQL默认的隔离级别是可重复读，SQL SERVER/ORACLE 是读已提交，隔离级别必须可以通过业务的实际场景指定。

1. 脏读：其他事务读取到了当前事务未提交的数据，比如发工资是一个事务，如发工资的过程中先修改了余额，再转账。如果其他事务查询工资余额，当发工资事务还未执行转账，但是查工资事务已经查询了未提交的修改余额，导致了钱没到账余额却变了，这就是脏读。
2. 不可重复度：在一个事务第一次读取数据后，另一个事务修改了数据，导致第一个事务第二次读取数据时，出现了两次数据的不一致。
3. 幻读 在第一个事务读取了一部分数据后，另一个事务插入了新的数据，导致两次读取的条数不一致。

		脏读	不可重复读	幻读
TransactionDefinition.ISOLATION_READ_UNCOMMITTED	允许读取尚未提交的数据变更(最低的隔离级别)	是	是	是
TransactionDefinition.ISOLATION_READ_COMMITTED	允许读取并发事务已经提交的数据	否	是	是
TransactionDefinition.ISOLATION_REPEATABLE_READ	对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改	否	否	是
TransactionDefinition.ISOLATION_SERIALIZABLE	最高的隔离级别，完全服从ACID的隔离级别，也是最慢的事务隔离级别，因为它通常是通过完全锁定事务相关的数据库表来实现的	否	否	否

5.事务的传播方式

当前默认实现是第一种，4和7两种传播方式比较特别，可以深入的研究下，这里不再多说，需要注意的是，当你利用了4这种会新建一个事务的传播方式后，当前事务和原有事务将产生事务隔离，在默认的隔离级别实现下（MYSQL 可重复读），内层事务将无法访问外层未提交的数据

1. PROPAGATION_REQUIRED(默认实现)：当前没有事务则新建事务，有则加入当前事务
2. PROPAGATION_SUPPORTS： 支持当前事务，如果当前没有事务则以非事务方式执行
3. PROPAGATION_MANDATORY： 使用当前事务，如果没有则抛出异常
4. PROPAGATION__REQUIRES_NEW： 新建事务，如果当前有事务则把当前事务挂起（内层影响外层，外层不影响内层）
5. PROPAGATION_NOT_SUPPORIED： 以非事务的方式执行，如果当前有事务则把当前事务挂起
6. PROPAGATION_NEVER： 以非事务的方式执行，如果当前有事务则抛出异常
7. PROPAGATION_NESTED： 如果当前存在事务，则在嵌套事务内执行，如果当前没有事务则执行1（内层try catch不影响外层，外层影响内层）

6.rollbackfor & noRollBackFor

rollBackFor属性可以指定事务遇到哪种异常的时候回滚，noRollBackfor则是事务遇到哪种异常时不回滚。在不指定rollBackfor是，默认为RuntimeException。通常情况下，可以指定Exception.class，当然这需要从实际业务出发。
有一点需要注意，那就是无法通过noRollBackFor=RuntimeException.class 来阻止运行时异常的回滚，由于回滚判断的源码实现，RuntimeException&error 无法通过NoRollBackFor来阻止事务回滚。

常见的事务不生效场景

这里不介绍一些会被IDEA 识别的场景，例如加事注解的方法非公有方法将导致事务不生效。

1. 同一个类中非事务方法调用了一个事务方法。
2. 指定回滚的异常级别不包含发生的异常（rollbackfor=RuntimeException）不包含SqlException）
3. 事务方法中多线程调用了方法，其他线程中的方法报错。

特殊的报错

1. Transaction rolled back because it has been marked as rollback-only

这种错误出现在,一个带有事务的方法注解调用并且try catch了另一个带有事务注解的方法，内部方法报错，但被try catch 然后因为内部方法带有事务注解，报错导致的事务的失败（并且由于两者注解的传播方式都是默认，因此两个事务注解实际上是一个事务），但是错误被捕获，因此上层方法继续执行，直接事务提交的时候，检查到事务在内部方法时已经失败，所以回滚.
解决方式有多种，按照实际需求出发

@Transactional
public void save(){
    try{
        this.insert();
    }catech(Exception e){
        
    }
    
}

@Transactional
public void insert(){
    int i = 1/0;
}