Spring 事务

从SpringBoot入手,从屁股开始往回学Spring,本次学习事务内容,也有常常被问到你这个spring事务怎么管理的,这个传播事务是怎么处理的等等问题,无论这么多,一点一点回舔

 

事务

事务指逻辑上的一组操做,要么所有成功,要么所有失败

网上也有不少例子,转帐的例子最多,赚钱方和收钱方要么一块儿成功,要么一块儿失败的过程控制

也有熟悉的数据库事务的4个特性: 原子性、隔离性、持久性、一致性 

这4个特性从大学就背记了,当时为了考试,谁管他是什么,及格才是王道

原子性:事务是一个不可分隔的工做单元,要么所有成功,要么所有失败

一致性:事务先后数据的完整性必须保持一致

隔离性:多用户并发访问数据,某一用户的事务不会被其余用户事务干扰,多个并发事务之间具备互相隔离

持久性:某一事务一旦被提交,它对数据库中数据的改变是永久的

 

若是不考虑事务隔离性的问题,则会有如下安全性的问题:

脏读:A事务读到B事务尚未提交的数据,若是B事务失败回滚,则A事务读到的数据就是脏数据

不可重复读:在同一个事务中,A事务读取到的B事务已经提交更新的数据,致使A事务不正确,屡次读取同一数据返回的结果不一样

幻读:A事务执行一部分,B事务插入记录,引发后续的事务的问题

mysql数据库默认是 repeatable_read

oracle数据库默认是 read_committed

 

Spring事务管理API

Spring提供一组接口,进行事务管理,主要一下3个:

①PlatformTransactionManager:事务管理器,包含事务状态、提交、回滚等

spring会根据不一样的ORM来选择不一样的接口实现类,好比下面几个: 

 

②TransactionDefinition:事务定义信息,包括事务操做的隔离级别、传播行为、是否超时、是否只读等

③TransactionStatus:事务状态,事务具体的运行状态,有是不是新事务、是否已经提交、是否完成等等

 

事务传播行为

在通常的服务中会有三层结构: web层 、业务层 、持久层

事务通常都会在加在业务层中,假设目前存在下面一些操做方法: 

持久层: Dao0有一个 x方法 ;  Dao1有一个 y方法 ; Dao2有一个 z方法

业务层: Service0 中有一个z方法,同时调用了Dao0.x()和Dao1.y() ; Service1 有一个v方法,调用了Dao2.z()

平时这两个业务单独的完成各自的任务接口没有问题,这时候产品出了一个需求,须要Service0,Service1一块儿处理一个接口结果

Service0,Service1都有事务,就会出现事务的传播行为,如下是七种行为 : 

前三个是一类,中间三个是一类,最后一个是一类,总共分三类

用第一个说明 ,若是同时调用Service0、Service1的时候,Service0存在事务,则0,1都使用Service0的事务;若是Service0没有事务,在Service1时,就建立一个事务,将Service0包含在内 --- Service0,Service1会在同一个事务中处理

第二类 Service0,Service1不在同一个事务中

第三类传播比较复杂,嵌套事务,在一个事务中设置一个保存点标志,和另外一个事务的成功与否相关

 

-------------------------------------------------------------------