事务的隔离级别和幻读问题

 

事务的隔离级别,是一个很基本的概念,从自己的角度整理一下.

 

分为两部分,一个是事务.一个是隔离级别.

 

第一个:事务

ACID是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：

原子性（Atomicity）

一致性（Consistency）

隔离性（Isolation）

持久性（Durability）

 

一个用户的操作可能要修改两张数据表,这个操作对应程序中的方法.以下是示例代码,没有真实意义,只是为了说明.

 

  /**
     * 更新项目的站点,示例代码没有意义
     * @param pid 项目ID
     * @param lid 站点ID
     * @return
     */
    public String updateProject(Integer projectId,Integer siteId){
        projectDAO.updateProjectLogicSite(projectId, siteId);
        siteDAO.addProject(projectId, siteId);
    }

 如果下面的站点加入项目失败

siteDAO.addProject(projectId, siteId);   //失败,DB中没有生效

但是下面的代码生效了

projectDAO.updateProjectLogicSite(projectId, siteId);//这个DB中生效了

 

因为上面的两句代码是两个事务了.使这个方法整体作为一个事务,(spring事务管理,使用注释方式)

/**
     * 更新项目的站点
     * @param pid 项目ID
     * @param lid 站点ID
     * @return
     */
    @Transactional(isolation=Isolation.REPEATABLE_READ)
    public String updateProject(Integer pid,Integer lid){
        projectDAO.updateProjectLogicSite(pid, lid);
        siteDAO.addProject(pid, lid);
    }

 那么,第二个更新站点失败,第一个更新项目也会一起回滚.

具体可以参考spring,和db的事务概率.

 

第二个 隔离级别

那么使用哪个隔离级别呢?

Spring提供了五个可选参数,对应了事务的四个隔离级别(怎么5个对应4个呢?看了就知道)

@Transactional(isolation=Isolation.DEFAULT)  //默认使用DB的隔离级别,如果是mysql的innodb默认是REPEATABLE_READ
@Transactional(isolation=Isolation.READ_UNCOMMITTED)
@Transactional(isolation=Isolation.READ_COMMITTED)
@Transactional(isolation=Isolation.REPEATABLE_READ)
@Transactional(isolation=Isolation.SERIALIZABLE)

 每个隔离级别的意思和介绍很多书和文章都讲解的很好,我就不重复了,下面按我自己的思路理一下

 

假设有TA和TB两个方法.都假设一个方法中有两个或者多个DB操作.

从两方面来说明.

A.是否阻塞其他事务往下执行

 

   1.TA是读操作先执行   TB是读操作后执行  无论两个方法的隔离级别是什么都不影响.

   2.TA是读操作先执行   TB是写操作后执行 只有TA是SERIALIZABLE才会被阻塞.其他时候都不会被阻塞.

   3.TA是写操作先执行   TB是读操作后执行  只有TB是SERIALIZABLE才会被阻塞.其他时候都不会被阻塞.

   4.TA是写操作先执行   TB是写操作后执行  只有TA没有事务,TB不会被阻塞,其他时候都要等TA操作完成.

 

注意(第4点,这里更严格的表示应该是TA的这个方法没有执行完,TB会被阻塞,方法没有声明为一个事务的时候TA一个DB操作就是一个事务,这个DB操作的时候,是会阻塞TA的写操作的)

 

B.读到的数据

首先假设一个场景是,TA是读操作先执行  然后TB是写操作,TA再次读取读到的是什么.其实只有这一个场景有问题,其他时候都是正常的操作.或者说TA先写,TB读,这个时候其实是第一个场景的后半部分.下面来列出什么情况读到什么.

TA1和TA2是TA这个方法中的两个读方法

1.TA没有事务   无论TB这个事务是否提交 TA2读到的都是TB写的数据.(更新丢失)

2.TA有事务,隔离级别READ_UNCOMMITTED  无论TB是否提交 TA2读到的都是TB写的数据  (和上面的区别是没有第一中更新丢失,但是TB回滚TA2会脏读)

3.TA有事务,隔离级别READ_COMMITTED  TA2读到的都是TB事务提交后的数据,没有提交读不到.(没有脏读,TA1读和TA2读到的不一致)

4.TA有事务 隔离级别REPEATABLE_READ   TA2读到的数据和TA1一样无论TB是否有提交(所以可以重复读,这里有幻读的问题,下面专门介绍幻读)

5.TA有事务 隔离级别SERIALIZABLE  TA2读到的和TA1一样,幻读都没有,看阻隔就知道,有写的时候都是排队来的.

幻读

专门理一下幻读,幻读发生在读一张表中不同行的数据时.

比如TA1读操作  select * from project where create_date > '20100101' 第一次查询有2条记录.

TB写操作     插入一条记录创建时间大于20100101的记录

TA2 再读 就读出3条记录了,这个时候就幻读了.

因为REPEATABLE_READ的时候TB是可以同时写的就有这个问题.

SERIALIZABLE是排队的,TB只有在TA的两次读操作都完成后才可以写,所以是完全没有问题的.

 

幻读导致的问题1

比如注册用户,希望用户名不重名.

TA和TB要注册用户gtbald.

TA1查询不存在gtbald.

TB1查询不存在gtbald.

TA2插入gtbald

TB2插入gtblad.

有两个gtbald了.

目前我知道的解决办法可以是DB用户名加上唯一索引.或者业务中注册事务隔离级别设为SERIALIZABLE(性能差).

 

幻读导致的问题2

比如报名人数限制为100人

TA和TB都要提交报名人

TA1查询总报名人数99人

TB1查询总报名人数99人

TA2增加报名一人 现在总报名人数100人

TB2增加报名一人  现在总报名人数101人

 

目前我知道的解决办法:报名务隔离级别设为SERIALIZABLE(性能差).

接下来研究幻读问题的解决方案.