学习基于记录，而不止于记录。

希望自己能坚持下去~

0.写在前面

import org.springframework.transaction.annotation.Transactional
@Transactional这个注解开发中很常见很常用，但是关于这个注解还可以展开聊一聊spring中的事务处理。

spring boot版本：2.0.8.RELEASE

1.关于事务

事务管理是应用系统开发中必不可少的一部分。Spring 为事务管理提供了丰富的功能支持。Spring 事务管理分为编码式和声明式的两种方式。编程式事务指的是通过编码方式实现事务；声明式事务基于 AOP,将具体业务逻辑与事务处理解耦。声明式事务管理使业务代码逻辑不受污染, 因此在实际使用中声明式事务用的比较多。声明式事务有两种方式，一种是在配置文件（xml）中做相关的事务规则声明，另一种是基于@Transactional 注解的方式。注释配置是目前流行的使用方式，因此本文将着重介绍基于@Transactional 注解的事务管理。概览如下：

image.png

事务四大特性:
1.原子性（Atomicity）
原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。

一致性（Consistency)
事务必须使数据库从一个一致性状态变换到另外一个一致性状态。(数据不被破坏)

3.隔离性（Isolation）
事务的隔离性是指一个事务的执行不能被其他事务干扰.

4.持久性（Durability）
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的.即使系统重启也不会丢失.

2.常规用法

以spring boot开发为例，通常在serviceImpl方法上加@Transactional注解，即可实现事务控制。

疑惑：为什么要在service层加事务控制，而不是Dao层？

如果事务直接在Dao层声明，持久层每一次操作就会产生一次事务提交，无法保证事务的一致性。而service层编写逻辑代码，会存在多次持久层操作，在这层使用事务处理恰到好处。也有一些事务会放在controller，但是出于开发规范考虑通常都放在service层。

3.使用细节

3.1 数据库必须支持事务

3.2必须在实例化spring bean的类中使用

比如我们的service通常会使用@service注解，就是为了装配成为spring bean。

3.3注解的方法必须是public声明

3.4自我调用

场景：
在service层A方法(无注解)调用B方法(有注解)，直接用this.B(params)，会导致事务失效。
解决方案
使用延迟注入@Lazy

@Slf4j
@Service(value = "tUserServiceImpl")
public class TUserServiceImpl implements TUserService {
    @Lazy
    private TUserService tUserService;
}

原因
这和3.2特性有关，使用延迟注入可以将装配成spring bean的service层bean注入自身，然后通过注入的bean来调用其他方法，而不影响事务处理了。

强烈推荐看看这篇文章知乎:玩转Spring —— 消失的事务，说的很详细。
摘录：
由于methodA没有加@Transactional注解，所以代理对象里面，直接就是target.methodA()，直接调用了原来对象的methodA。
这下就很清晰了，代理对象的methodA，去调用原来对象的methodA，原来对象的methodA，再去调用原来对象的methodB，而原来对象的methodB，是不具有事务的。事务只存在于代理对象的methodB. 所以整个方法也就没有事务了。

这下就很清晰了，代理对象的methodA，去调用原来对象的methodA，原来对象的methodA，再去调用原来对象的methodB，而原来对象的methodB，是不具有事务的。事务只存在于代理对象的methodB. 所以整个方法也就没有事务了。

3.5关于异常

只捕获而不抛出事务不会生效
抛出异常必须是RuntimeException，自定义或者其他类型的异常，事务也不生效

exception_relation.png

那如果我需要自定义异常回滚，怎么办？

使用rollbackFor ，声明为哪些异常进行回滚

@Transactional(rollbackFor = [MyException::class])
@Throws(MyException::class)
public void catchThrowsExceptionWithTransactional() {
    try {
        Man man = new Man("1", Woman("1"))
        manRepository.save(man)
        throw new MyException("custom exception")
    } catch (MyException e) {
        throw e
    }
}

3.6事务传播，@Transactional(propagation = ?)

REQUIRED
如果没有就创建一个，如果有，就用当前的
REQUIRED_NEW
每次都会创建一个新的，如果当前就有一个，那么会把当前的挂起

区别：
REQUIRED 如果两个方法共享一个事务，一个需要回滚，一个需要提交，就会出现UnexpectedRollbackException；
REQUIRED_NEW 两个方法都有自己的事务，所以不会互相影响。

SUPPORTS 如果当前有事务就用，如果没有就不用事务的
NESTED 不建议使用，和JDBC版本有关

3.7Isolation 事务的隔离,@Transactional(isolation = ?)

Dirty read 脏读: read the uncommitted change of a concurrent transaction.
A事务在读取某一行数据的时候，能够读到B事务还未提交的、对同一行数据的修改。
Non-repeatable read 不可重复读: get different value on re-read of a row if a concurrent transaction updates
the same row and commits.
在同一个事务里，在T1时间读取到的某一行的数据，在T2时间再次读取同一行数据时，发生了变化。后者变化可能是被更新了、消失了。
Phantom read 幻读: get different rows after re-execution of a range query if another transaction adds or
removes some rows in the range and commits.
在同一个事务里，用条件A，在T1时间查询到的数据是10行，但是在T2时间查询到的数据多于10行。需要注意的是，
和 Nonrepeatable read 不同，Phantom read 在T1时读到的数据在T2时不会发生变化。注意，为何只说比10行多，
那么比10行少就不是 Phantom read 了吗？因为 Nonrepeatable read 包含了数据消失的情况。

隔离等级	脏读	不可重复读	幻读
READ_UNCOMMITTED	可能发生	可能发生	可能发生
READ_COMMITTED		可能发生	可能发生
REPEATABLE_READ			可能发生
SERIALIZABLE

注意：
虽然SERIALIZABLE可以避免所有异常情况，但是不建议，因为效率太低了。

4. 总结

以上就是对于@Transational事务注解的一些总结，有一些我已经测试过了，但是有部分我只是从其他博客或者学习视频参考过来的，所以得找个时间验证。

关于@Transactional注解漫谈事务_2020.05.07