spring 传播行为与数据库事务ACID

数据库事务ACID特性

　　数据库事务正确执行的4个基础要素是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。
　　•原子性：整个事务中的全部操做，要么所有完成，要么所有不完成，不可能停滞在中间某个环节。事务在执行过程当中发生错误，会被回滚到事务开始前的状态，就像这个事务历来没被执行过同样。
　　•一致性：指一个事务能够改变封装状态（除非它是一个只读的）。事务必须始终保持系统处于一致的状态，无论在任何给定的时间并发事务有多少。
　　•隔离性：它是指两个事务之间的隔离程度。
　　•持久性：在事务完成之后，该事务对数据库所作的更改便持久保存在数据库之中，并不会被回滚。
　　这里的原子性、一致性和持久性都比较好理解，而隔离性就不同了，它涉及了多个事务并发的状态。首先多个事务并发会产生数据库丢失更新的问题，其次隔离性又分为多个层级。

 

隔离级别

　　隔离级别能够在不一样程度上减小丢失更新，那么对于隔离级别数据库标准是怎么定义的呢？按照SQL的标准规范（还有些人认为这是Spring或者Java的规范，而事实是SQL的规范，Spring或者Java只是按照SQL的规范定义的而已），把隔离级别定义为4层，分别是：脏读（dirty read）、读/写提交（readcommit）、可重复读（repeatable read）和序列化（Serializable）。

　　 脏读是最低的隔离级别，其含义是容许一个事务去读取另外一个事务中未提交的数据。以丢失更新的消费为例进行说明，如表所示。

 

　　因为在T3时刻老婆启动了消费，致使余额为9 000元，老公在T4时刻消费，由于用了脏读，因此可以读取老婆消费的余额（注意，这个余额是事务二未提交的）为9 000元，这样余额就为8 000元了，因而T5时刻老公提交事务，余额变为了8 000元，老婆在T6时刻回滚事务，因为数据库克服了第一类丢失更新，因此余额依旧为8 000元，显然这是一个错误的余额，产生这个错误的根源来自于T4时刻，也就是事务一能够读取事务二未提交的事务，这样的场景被称为脏读。

　　为了克服脏读，SQL标注提出了第二个隔离级别—— 读/写提交。所谓读/写提交，就是说一个事务只能读取另外一个事务已经提交的数据。依旧以丢失更新的夫妻消费为例，如表所示。

 

　　在T3时刻，因为事务采起读/写提交的隔离级别，因此老公没法读取老婆未提交的9 000元余额，他只能读到余额为10 000元，因此在消费后余额依旧为9 000元。在T5时刻提交事务，而T6时刻老婆回滚事务，因此结果为正确的9 000元，这样就消除了脏读带来的问题，可是也会引起其余的问题，如表所示。

 

　　因为T7时刻事务一知道事务二提交的结果——余额为1 000元，致使老公无钱买单的尴尬。对于老公而言，他并不知道老婆作了什么事情，可是帐户余额却莫名其妙地从10 000元变为了1000元，对他来讲帐户余额是不能重复读取的，而是一个会变化的值，这样的场景咱们称为 不可重复读（unrepeatable read），这是读/写提交存在的问题。

　　为了克服不可重复读带来的错误，SQL标准又提出了一个 可重复读的隔离级别来解决问题。注意，可重复读这个概念是针对数据库同一条记录而言的，换句话说，可重复读会使得同一条数据库记录的读/写按照一个序列化进行操做，不会产生交叉状况，这样就能保证同一条数据的一致性，进而保证上述场景的正确性。可是因为数据库并非只能针对一条数据进行读/写操做，在不少场景，数据库须要同时对多条记录进行读/写，这个时候就会产生下面的状况，如表所示。

 

　　老婆在T1查询到10条记录，到T4打印记录时，并不知道老公在T2和T3时刻进行了消费，致使多一条（可重复读是针对同一条记录而言的，而这里不是同一条记录）消费记录的产生，她会质疑这条多出来的记录是否是幻读出来的，这样的场景咱们称为幻读（phantom read）。

　　为了克服幻读，SQL标准又提出了 序列化的隔离级别。它是一种让SQL按照顺序读/写的方式，可以消除数据库事务之间并发产生数据不一致的问题。关于各种的隔离级别和产生的现象如表所示。

 

选择隔离级别和传播行为　　

　　选择隔离级别的出发点在于两点：性能和数据一致性，下面展开论述。
　　在互联网应用中，不但要考虑数据库数据的一致性，并且要考虑系统的性能。通常而言，从脏读到序列化，系统性能直线降低。所以设置高的级别，好比序列化，会严重压制并发，从而引起大量的线程挂起，直到得到锁才能进一步操做，而恢复时又须要大量的等待时间。所以在购物类的应用中，经过隔离级别控制数据一致性的方式被排除了，而对于脏读风险又过大。在大部分场景下，企业会选择读/写提交的方式设置事务。这样既有助于提升并发，又压制了脏读，可是对于数据一致性问题并无解决，后面会详细讨论如何去克服这类问题。对于通常的应用均可以使用@Transactional方法进行配置
　　代码清单：使用读/写提交隔离级别

@Autowired
private RoleDao roleDao = null;
//设置方法为读/写提交的隔离级别 
@Transaction(propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED)
public int insertRole(Role role) {
    return roleDao.insert(role);
}

 

　　固然也会有例外，并非说全部的业务都在高并发下完成，当业务并发量不是很大或者根本不须要考虑的状况下，使用序列化隔离级别用以保证数据的一致性，也是一个不错的选择。总之，隔离级别须要根据并发的大小和性能来作出决定，对于并发不大又要保证数据安全性的可使用序列化的隔离级别，这样就可以保证数据库在多事务环境中的一致性
　　代码清单：使用序列化隔离级别

@Autowired
private RoleDao roleDao = null;

//设置方法为序列化的隔离级别 
@Transaction(propagation = Propagation.REQUIRED, isolation = Isolation.SERIALIZABLE)
public int insertRole(Role role) {
    return roleDao.insert(role);
}

 

　　只是这样的代码会使得数据库的并发能力低下，在抢购商品的场景下出现卡顿的状况，因此在高并发的场景下这段代码并不适用

　　在实际工做中，注解@Transactional隔离级别的默认值为Isolation.DEFAULT，其含义是默认的，随数据库默认值的变化而变化。由于对于不一样的数据库而言，隔离级别的支持是不同的。好比MySQL能够支持4种隔离级别，而默认的是可重复读的隔离级别。而Oracle只能支持读/写提交和序列化两种隔离级别，默认为读/写提交，这些是在工做中须要注意的问题。

传播行为

　　传播行为是指方法之间的调用事务策略的问题。在大部分的状况下，咱们都但愿事务可以同时成功或者同时失败。可是也会有例外
　　在Spring中传播行为的类型，是经过一个枚举类型去定义的，这个枚举类是org.springframework.transaction.annota-tion.Propagation，它定义了如表所列举的7种传播行为。

 

文章来源:ssm 13.4,13.5