spring声明式事务

1.数据库ACID、事务隔离级别

2.spring事务相关的API

3.spring声明式事务

4.spring事务传播行为

5.sring事务原理

---

1.数据库ACID、事务隔离级别

此章节作为理论基础先行篇。
事务四个特性：
①原子性(Atomicity)
sql作为一个整体，要么全部成功,要么全部失败回滚。
②一致性(Consistency)
sql的执行完之后保持整体的一致性。
③隔离性(Isolation)
用于并发控制，实现并发执行的事务能够按照顺序执行
④持久性(Durability)
事务提交后，数据会持久化到磁盘中

在高并发场景下,要完全满足ACID是很困难的，除非将事务的执行设置为串行化,但是这样会导致性能下降，因此根据业务场景不同对事务的要求不同，数据库设计了四种隔离级别，供用户自行选择。

隔离级别	脏读	不可重复度	幻读
读未提交(read uncommitted)	√	√	√
读已提交(read committed)oracle默认隔离级别	❌	√	√
可重复读(repeatable read)mysql默认隔离级别	❌	❌	√
串行化(serializable)	❌	❌	❌

读未提交：

事务A可以读取其他事务未提交的修改

读未提交

读已提交：

事务A只能读取其他事务已提交的修改

读已提交

可重复读：

事务A在开启事务后,所读取的数据①当前事务未修改的数据读取的结果是开启事务之前一致②当前事务修改的数据再次读取是当前事务修改的值。

可重复读

串行化

数据库每次读写都会加锁,读读锁不会产生冲突,读写锁,写写锁时会产生冲突,例如下图,事务读取改行数据时会加读锁,导致事务B挂起,当事务A commit后释放读锁,事务B继续执行。

串行化

---

不同的数据隔离级别可能会导致的问题解释：

脏读:

当前事务读取了其他事务未提交的修改数据

不可重复读:

当前事务前后读取的同一条数据结果不一致。

幻读：

当前事务内,读取一个范围内的记录，前后结果不一致(记录减少或记录增加)
比如select count(1) from table T where a>1 结果为5，在当前事务内再次执行发现结果为10

对于隔离级别为可重复读下,mysql通过MVCC(多版本并发控制)基本可以帮我们解决掉幻读问题,但是对于update/delete问题还是解决不了的。
读提交、不可重复读 的隔离级别之所以可以将数据隔离，是因为数据库引擎引入的视图(read-view)的概念,可以对数据生成快照,结合回滚日志实现的。
此处只是简单提一下，目前打算放在之后数据库专栏分析该问题。

2.spring事务相关的API

TransactionDefinition 事务定义相关类
PlatformTransactionManager 事务管理类
TransactionStatus 事务运行时相关的状态

TransactionDefinition
PlatformTransactionManager
TransactionStatus

3.spring声明式事务

为了简化对事物的控制,spring提出了声明式事务,简化了对事务的操作。

• spring配置文件

<!--配置包扫描-->
    <context:component-scan base-package="com.ckd"/>
    <!--配置数据源-->
    <bean id="datasource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
        <property name="url" value="jdbc:mysql://master:3306/dck"/>
        <property name="username" value="root"/>
        <property name="password" value="root"/>
    </bean>
     <!--JDBCTemplate-->
    <bean class="org.springframework.jdbc.core.JdbcTemplate">
        <property name="dataSource" ref="datasource"/>
    </bean>
    <!--配置事务管理器-->
    <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="datasource"/>
    </bean>
      <!--支持事务注解-->
    <tx:annotation-driven transaction-manager="txManager"/>

之后就可以用@Transactionnal注解了

4.spring事务传播行为

类别	事务传播行为	说明
支持当前事务	PROPAGATION_REQUIRED	当前存在事务，则加入到该事务中，没事务的话，新建一个事务(默认传播行为)
~	PROPAGATION_SUPPORTS	当前存在事务加入到该事务中，如果当前没有事务，则以非事务的方式运行
~	PROPAGATION_MANDATORY	支持当前事务，如果当前没有事务，则抛出异常
不支持当前事务	PROPAGATION_REQUIRES_NEW	不管当前有没有事务，都会新建一个事务
~	PROPAGATION_NOT_SUPPORT	以非事务的方式运行,如果当前存在事务，则将当前事务挂起
~	PROPAGATION_NEVER	以非事务的方式运行,如果当前存在事务，则抛出异常
嵌套事务	PROPAGATION_NESTED	如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作

PROPAGATION_REQUIRES_NEW、 PROPAGATION_NESTED这两个事务比较疑惑，因此单独提出来分析一下。

PROPAGATION_REQUIRES_NEW：

如下图在同一个线程中，在执行MethodA()时开启一个事务,调用serviceB.methodB()时会重新开启一个事务，执行methodA时的事务暂时挂起,由AbstractPlatformTransactionManager负责相应的线程及事务信息的保存处理(具体源码没研究过)。MethodB()执行完commit之后,MethodA恢复之前事务状态,继续执行。
因此结论是:
MethodB执行的异常回滚并不会影响methodA的回滚操作，两个事务互不影响。

class ServiceA{
       @Transactional(propagation = Propagation.REQUIRED)
       methodA(){
              serviceB.methodB();
       }
}
class ServiceB{
       @Transactional(propagation = Propagation.REQUIRES_NEW)
       methodB(){
       }
}

PROPAGATION_NESTED：

PROPAGATION_NESTED作为一个嵌套事务,实际上是serviceB.methodB()作为methodA执行时开启的事务的一个子事务,两者本质上是同一个事务,在执行到serviceB.methodB()会通过savePoint(参见TransactionStatus类)机制记录执行位置,当methodB发生异常时,会通过savePoint将methodB执行的sql语句回滚,methodA并不受影响(前提时异常捕获了)。

class ServiceA{
       @Transactional(propagation = Propagation.REQUIRED)
       methodA(){
              serviceB.methodB();
       }
}
class ServiceB{
       @Transactional(propagation = Propagation.NESTED)       
       methodB(){
       }
}

---

5.sring事务原理