数据库的事务基本特性
事物是区分文件存储系统与Nosql数据库重要特性之一,其存在的意义是为了保证即使在并发情况下也能正确的执行crud操作。怎样才算是正确的呢?这时提出了事物需要保证的四个特性即ACID:
- A: 原子性(atomicity) 
 事物中各项操作,要么全做要么全不做,任何一项操作的失败都会导致整个事物的失败;
- C: 一致性(consistency) 
 事物结束后系统状态是一致的;
- I: 隔离性(isolation) 
 并发执行的事物彼此无法看到对方的中间状态;
- D: 持久性(durability) 
 事物完成后所做的改动都会被持久化,即使发生灾难性的失败。
在高并发的情况下,要完全保证其ACID特性是非常困难的,除非把所有的事物串行化执行,但带来的负面的影响将是性能大打折扣。很多时候我们有些业务对事物的要求是不一样的,所以数据库中设计了四种隔离级别,供用户基于业务进行选择。

- 脏读 : 
 一个事物读取到另一事物未提交的更新数据
- 不可重复读 : 
 在同一事物中,多次读取同一数据返回的结果有所不同, 换句话说, 后续读取可以读到另一事物已提交的更新数据. 相反, “可重复读”在同一事物中多次读取数据时, 能够保证所读数据一样, 也就是后续读取不能读到另一事物已提交的更新数据。
- 幻读 : 
 查询表中一条数据如果不存在就插入一条,并发的时候却发现,里面居然有两条相同的数据。这就幻读的问题。
数据库默认隔离级别:
- Oracle中默认级别是 Read committed
- mysql 中默认级别 Repeatable read。另外要注意的是mysql 执行一条查询语句默认是一个独立的事物,所以看上去效果跟Read committed一样。
查看mysql 的默认隔离级别
SELECT @@tx_isolation
Spring对事务的支持与使用
spring 事物相关API说明
spring 事物是在数据库事物的基础上进行封装扩展,其主要特性如下:
- 支持原有的数据事物的隔离级别;
- 加入了事物传播的概念,提供多个事物的合并或隔离的功能;
- 提供声明式事物,让业务代码与事物分离,事物变得更易用;
怎么样去使用Spring事物呢?spring提供了三个接口供使用事物。分别是:
- TransactionDefinition
 事物定义
- PlatformTransactionManager
 事物管理
- TransactionStatus
 事物运行时状态
接口结构图:

基于API实现事物
| 1 | public class SpringTransactionExample { | 
声明示事物
我们前面是通过调用API来实现对事物的控制,这非常的繁琐,与直接操作JDBC事物并没有太多的改善,所以Spring提出了声明示事物,使我们对事物的操作变得非常简单,甚至不需要关心它。
- 配置spring.xml
| 1 | 
 | 
- 编写服务类
| 1 | 
 | 
事物传播机制
| 类别 | 事务传播类型 | 说明 | 
| 支持当前事务 | PROPAGATION_REQUIRED (必须的) | 如果当前没有事物,就新建一个事物,如果已经存在一个事物中, 加入到这个事物中。这是最常见的选择 | 
| PROPAGATION_SUPPORTS (支持) | 支持当前事物,如果当前没有事物,就以非事物方式执行 | |
| PROPAGATION_MANDATORY (强制) | 使用当前的事物,如果当前没有事物,就抛出异常 | |
| 不支持当前事物 | PROPAGATION_REQUIRES_NEW (隔离) | 新建事物,如果当前存在事物,把当前事物挂起 | 
| PROPAGATION_NOT_SUPPORTED (不支持) | 以非事物方式执行操作,如果当前存在事物,就把当前事物挂起 | |
| PROPAGATION_NEVER (强制非事物) | 以非事物方式执行,如果当前存在事物,则抛出异常 | |
| 嵌套事物 | PROPAGATION_NESTED (嵌套事物) | 如果当前存在事物,则在嵌套事物内执行。如果当前没有事物, 则执行与PROPAGATION_REQUIRED类似的操作。 | 
常用事物传播机制:
- PROPAGATION_REQUIRED 
 这个也是默认的传播机制;
- PROPAGATION_NOT_SUPPORTED 
 可以用于发送提示消息,站内信、短信、邮件提示等。不属于并且不应当影响主体业务逻辑,即使发送失败也不应该对主体业务逻辑回滚;
- PROPAGATION_REQUIRES_NEW 
 总是新启一个事物,这个传播机制适用于不受父方法事物影响的操作,比如某些业务场景下需要记录业务日志,用于异步反查,那么不管主体业务逻辑是否完成,日志都需要记录下来,不能因为主体业务逻辑报错而丢失日志;
演示常用事物的传播机制
用例1:
创建用户时初始化一个帐户,表结构和服务类如下。
| 表结构 | 服务类 | 功能描述 | 
|---|---|---|
| user | UserService | 创建用户并添加账户 | 
| account | AccountService | 添加账户 | 
UserSerivce.createUser(name) 实现代码:
| 1 | 
 | 
AccountService.addAccount(name,initMoney) 实现代码(方法的最后有一个异常):
| 1 | (propagation = Propagation.REQUIRED) | 
实验预测:

AOP事务底层实现原理
讲事物原理之前我们先来做一个实验,当场景五的环境改变,把 addAccount 方法移至UserService类下,其它配置和代码不变:
| 1 | 
 | 
经过测试我们发现得出的结果与场景五并不一至,required_new 没有起到其对应的作用。原因在于 spring 声明示事物使用动态代理实现,而当调用同一个类的方法时,是会不会走代理逻辑的,自然事物的配置也会失效。
通过一个动态代理的实现来模拟这种场景
UserService.java
| 1 | public interface UserService { | 
UserServiceImpl.java
| 1 | public class UserServiceImpl implements UserService { | 
TransactionProxy.java
| 1 | public class TransactionProxy { | 
当我们调用 createUser 方法时, 仅打印了 createUser  的事物开启、关闭,并没有打印addAccount方法的事物开启、关闭,由此可见 addAccount  的事物配置是失效的。