Spring支持的常用数据库事务传播属性和事务隔离级别
代码
@Transactional(propagation=Propagation.REQUIRED,isolation=Isolation.READ_COMMITTED)
事务的属性:
- ★propagation:用来设置事务的传播行为
事务的传播行为:一个方法运行在了一个开启了事务的方法中时,当前方法是使用原来的事务还是开启一个新的事务
-Propagation.REQUIRED:默认值,使用原来的事务
-Propagation.REQUIRES_NEW:将原来的事务挂起,开启一个新的事务 - ★isolation:用来设置事务的隔离级别
-Isolation.REPEATABLE_READ:可重复读,MySQL默认的隔离级别
-Isolation.READ_COMMITTED:读已提交,Oracle默认的隔离级别,开发时通常使用的隔离级别
事务的传播行为
简介
Spring在TransactionDefinition接口中规定了7种类型的事务传播行为。事务传播行为是Spring框架独有的事务增强特性,他不属于的事务实际提供方数据库行为。这是Spring为我们提供的强大的工具箱,使用事务传播行可以为我们的开发工作提供许多便利。但是人们对他的误解也颇多,你一定也听过“service方法事务最好不要嵌套”的传言。要想正确的使用工具首先需要了解工具。本文对七种事务传播行为做详细介绍,内容主要代码示例的方式呈现。
Spring中七种事务传播行为
事务传播行为类型 | 说明 |
---|---|
PROPAGATION_REQUIRED | 如果当前没有事务,就新建一个事务,如果已经存在一个事务中,加入到这个事务中。这是最常见的选择。 |
PROPAGATION_SUPPORTS | 支持当前事务,如果当前没有事务,就以非事务方式执行。 |
PROPAGATION_MANDATORY | 使用当前的事务,如果当前没有事务,就抛出异常。 |
PROPAGATION_REQUIRES_NEW | 新建事务,如果当前存在事务,把当前事务挂起。 |
PROPAGATION_NOT_SUPPORTED | 以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。 |
PROPAGATION_NEVER | 以非事务方式执行,如果当前存在事务,则抛出异常。 |
PROPAGATION_NESTED | 如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则执行与PROPAGATION_REQUIRED |
隔离级别
数据库系统必须具有隔离并发运行各个事务的能力,是他们不会相互影响,避免各种并发问题。一个事务与其它事务隔离的程度称为隔离级别。SQL标准中规定了多种事务隔离级别,不同隔离级别对应不同的干扰程度,隔离级别越高,数据一致性就越好,但并发性越弱。
- 读未提交:READ UNCOMMITTED
允许Transaction01读取Transaction02未提交的修改 - 读已提交
要求Transaction01只能读取Transaction02已提交的修改 - 可重复读
确保Transaction01可以多次从一个字段中读取到相同的值,即Transaction01执行期间禁止其他事务对这个字段进行更新 - 串行化:
确保Transaction01可以多次从一个表中读取到相同的行,在Transaction01执行期间,进制其他事务对这个表进行添加、更新、删除操作。可以避免任何并发问题,但性能十分低下
脏读、不可重复读、幻读
假设现在有两个事务:Transaction01 和 Transaction02 并发执行
- 脏读-(读取到了某个事物未提交的数据)
* Transaction01将某条记录的AGE值从20修改为30
* Transaction02读取了Transaction01更新后的值:30
* Transaction01回滚,AGE值回复到了20
* Transaction02读取到的30就是一个无效的值 - 不可重复读-(某事务进行了两次读取,两次读取过程中另外一个事务进行了更新或删除提交,导致两次读取的数据不一致)
* Transaction01读取了AGE值为20;
* Transaction02将AGE值修改为30
* Transaction01再次读取AGE值为30,和第一次读取不一致 - 幻读-(事务1进行了查询过程中,事务2进行了插入操作,导致事务1看到的数据变多了)
* Transaction01读取了STUDENT表中的一部分数据,并到出Excel
* Transaction02向STUDENT表中出入了新的数据
* Transaction01导出的Excel数据莫名其妙的多了一些数据
各个隔离级别解决并发问题的能力
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
READ UNCOMMITTED | 有 | 有 | 有 |
READ COMMITTED | 无 | 有 | 有 |
REPEATABLE READ | 无 | 无 | 有 |
SERIALIZABLE | 无 | 无 | 无 |
各种数据库产品对事务隔离级别的支持程度
隔离级别 | Oracle | MySql |
---|---|---|
READ UNCOMMITTED | no | yes |
READ COMMITTED | yes(默认) | yes |
REPEATABLE READ | no | yes(默认) |
SERIALIZABLE | yes | yes |
总结
很多人容易搞混不可重复读和幻读,确实这两者有些相似。但不可重复读重点在于update和delete,而幻读的重点在于insert。
如果使用锁机制来实现这两种隔离级别,在可重复读中,该sql第一次读取到数据后,就将这些数据加锁,其它事务无法修改这些数据,就可以实现可重复读了。但这种方法却无法锁住insert的数据,所以当事务A先前读取了数据,或者修改了全部数据,事务B还是可以insert数据提交,这时事务A就会 发现莫名其妙多了一条之前没有的数据,这就是幻读,不能通过行锁来避免。
如果要解决幻读问题,需要Serializable隔离级别 ,读用读锁,写用写锁,读锁和写锁互斥,这么做可以有效的避免幻读、不可重复读、脏读等问题,但会极大的降低数据库的并发能力。