Spring事务管理与数据库隔离级别的关系（Spring+mysql）

数据库事务的隔离级别有4个，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。

 

√: 可能出现    ×: 不会出现

脏读不可重复读幻读Read uncommitted√√√Read committed×√√Repeatable read××√Serializable×××

 

注意：我们讨论隔离级别的场景，主要是在多个事务并发的情况下，因此，接下来的讲解都围绕事务并发。

Read uncommitted 读未提交

公司发工资了，领导把5000元打到singo的账号上，但是该事务并未提交，而singo正好去查看账户，发现工资已经到账，是5000元整，非常高兴。可是不幸的是，领导发现发给singo的工资金额不对，是2000元，于是迅速回滚了事务，修改金额后，将事务提交，最后singo实际的工资只有2000元，singo空欢喜一场。

 

出现上述情况，即我们所说的脏读，两个并发的事务，“事务A：领导给singo发工资”、“事务B：singo查询工资账户”，事务B读取了事务A尚未提交的数据。

当隔离级别设置为Read uncommitted时，就可能出现脏读，如何避免脏读，请看下一个隔离级别。

Read committed 读提交

singo拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好在网上转账，把singo工资卡的2000元转到另一账户，并在singo之前提交了事务，当singo扣款时，系统检查到singo的工资卡已经没有钱，扣款失败，singo十分纳闷，明明卡里有钱，为何......

出现上述情况，即我们所说的不可重复读，两个并发的事务，“事务A：singo消费”、“事务B：singo的老婆网上转账”，事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。

当隔离级别设置为Read committed时，避免了脏读，但是可能会造成不可重复读。

大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。如何解决不可重复读这一问题，请看下一个隔离级别。

Repeatable read 重复读

当隔离级别设置为Repeatable read时，可以避免不可重复读。当singo拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），singo的老婆就不可能对该记录进行修改，也就是singo的老婆不能在此时转账。

虽然Repeatable read避免了不可重复读，但还有可能出现幻读。

singo的老婆工作在银行部门，她时常通过银行内部系统查看singo的信用卡消费记录。有一天，她正在查询到singo当月信用卡的总消费金额（select sum(amount) from transaction where month = 本月）为80元，而singo此时正好在外面胡吃海塞后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction ... ），并提交了事务，随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上，却发现消费总额为1080元，singo的老婆很诧异，以为出现了幻觉，幻读就这样产生了。

注：MySQL的默认隔离级别就是Repeatable read。

Serializable 序列化

Serializable是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻像读。

首先我来描述一下，数据库（mysql）层面上对于事务传播行为和隔离级别的配置和实验方法：

数据库层面（采用命令行）：其实mySql命令行很简单，希望实验操作一下：

//连接数据库，我这里是本地，后面是用户名密码，不要打分号，如果指令不行，配置下环境变量，网上有很多。

1. cmd中执行：mysql -hlocalhost -uroot -pmysql   

//查看本地数据库事务传播行为是手动提交（0），还是自动提交（1）。

2.select @@autocommit;

//如果是0，希望设置为手动提交,这里其实是设置本对话的autocommit，因为如果你再开一个cmd，发现还是没改回来，如果想修改全局的，网上有global方法。

3.set @@autocommit=0;

//然后查询本地数据库中的一条记录,我本地数据库为test1;

4.use test1;

5.select * from task where taskid=1;

//同时新开一个窗口cmd，连接数据库，并且修改这条记录，update语句我就不写了，或者直接修改数据库本条记录。

//再次执行select * from task where taskid=1;发现值没变。OK因为此时数据库隔离级别为repeatable read 重复读，因为mysql默认的隔离级别是重复读。

//修改数据库隔离级别

6.set global transaction isolation level read committed;

//查看一下，可能需要重新连接一下

7.select @@tx_isolation;

//这时在执行一下4,5操作，发现值变了，ok。因为已经改变了数据库隔离级别，发生了重复读出不同数据的现象。

（以上操作希望有不明白的上网自学一下，很有用，先把数据库隔离级别弄明白了）

然后再来讲一下，Spring对事务传播行为和隔离级别的二次封装。

因为不同项目可能在一个mysql的不同数据库上，所以可以在项目中配置数据库的传播行为和隔离级别：

关于spring的传播行为（PROPAGATION_REQUIRED、PROPAGATION_REQUIRED等），我《数据库隔离级别（mysql+Spring）与性能分析 》文章中有讲，网上也有很多相关资料，我就不说了。

关于spring的事务隔离级别与数据库的一样，也是那四个，多了一个default，我也不仔细讲了。

下面主要讲一下spring的配置方法：

<property name="transactionAttributes"> 
<props> 
<prop key="save*">PROPAGATION_REQUIRED</prop> 
<prop key="update*">PROPAGATION_REQUIRED</prop> 
<prop key="delete*">PROPAGATION_REQUIRED</prop> 
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop> 
<prop key="find*">PROPAGATION_REQUIRED,ISOLATION_READ_UNCOMMITTED</prop>
</props>

就以find为例，可以配置这么配置，前面是控制传播行为，后面是控制事务隔离级别的。那么这时哪怕数据库层面上是重复读，但是还是以这里为准，你会发现在同一个事务中两次查询的结果是不一样的。

最后扫除一个盲区，readonly这个属性，是放在传播行为中的，一般书都这么归类，我也尝试了一下，readonly并不能影响数据库隔离级别，只是配置之后，不允许在事务中对数据库进行修改操作，仅此而已。