什么是事务？
事务由一组操作构成，我们希望这组操作能够全部正确执行，如果这一组操作中的任意一个步骤发生错误，那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作，要么全都正确执行，要么全都不要执行。
事务的四大特性 ACID
说到事务，就不得不提一下事务著名的四大特性。
- 原子性
原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。
- 一致性
一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。
- 隔离性
事务的执行是相互独立的，它们不会相互干扰，一个事务不会看到另一个正在运行过程中的事务的数据。
- 持久性
持久性要求，一个事务完成之后，事务的执行结果必须是持久化保存的。即使数据库发生崩溃，在数据库恢复后事务提交的结果仍然不会丢失。
注意：事务只能保证数据库的高可靠性，即数据库本身发生问题后，事务提交后的数据仍然能恢复；而如果不是数据库本身的故障，如硬盘损坏了，那么事务提交的数据可能就丢失了。这属于『高可用性』的范畴。因此，事务只能保证数据库的『高可靠性』，而『高可用性』需要整个系统共同配合实现。
事务的隔离级别
这里扩展一下，对事务的隔离性做一个详细的解释。
在事务的四大特性ACID中，要求的隔离性是一种严格意义上的隔离，也就是多个事务是串行执行的，彼此之间不会受到任何干扰。这确实能够完全保证数据的安全性，但在实际业务系统中，这种方式性能不高。因此，数据库定义了四种隔离级别，隔离级别和数据库的性能是呈反比的，隔离级别越低，数据库性能越高，而隔离级别越高，数据库性能越差。
事务并发执行会出现的问题
-
更新丢失
当有两个并发执行的事务，更新同一行数据，那么有可能一个事务会把另一个事务的更新覆盖掉。
当数据库没有加任何锁操作的情况下会发生。 -
脏读
一个事务读到另一个尚未提交的事务中的数据。
该数据可能会被回滚从而失效。
如果第一个事务拿着失效的数据去处理那就发生错误了。 -
不可重复读
不可重复度的含义：一个事务对同一行数据读了两次，却得到了不同的结果。它具体分为如下两种情况：- 虚读：在事务1两次读取同一记录的过程中，事务2对该记录进行了修改，从而事务1第二次读到了不一样的记录。
- 幻读：事务1在两次查询的过程中，事务2对该表进行了插入、删除操作，从而事务1第二次查询的结果发生了变化。
不可重复读 与 脏读 的区别？ 脏读读到的是尚未提交的数据，而不可重复读读到的是已经提交的数据，只不过在两次读的过程中数据被另一个事务改过了。
数据库的四种隔离级别
数据库一共有如下四种隔离级别：
-
Read uncommitted 读未提交
在该级别下，一个事务对一行数据修改的过程中，不允许另一个事务对该行数据进行修改，但允许另一个事务对该行数据读。
因此本级别下，不会出现更新丢失，但会出现脏读、不可重复读。
-
Read committed 读已提交
在该级别下，未提交的写事务不允许其他事务访问该行，因此不会出现脏读；但是读取数据的事务允许其他事务的访问该行数据，因此会出现不可重复读的情况。
-
Repeatable read 可重复读
在该级别下，读事务禁止写事务，但允许读事务，因此不会出现同一事务两次读到不同的数据的情况（不可重复读），且写事务禁止其他一切事务。
-
Serializable 序列化
该级别要求所有事务都必须串行执行，因此能避免一切因并发引起的问题，但效率很低。
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 读未提交(Read uncommitted) | √ | √ | √ |
| 读已提交(Read committed) | × | √ | √ |
| 可重复读(Repeatable read) | × | × | √ |
| 可串行化(Serializable ) | × | × | × |
Spring中七种事务传播行为
| 序号 | 事务传播行为类型 | 说明 |
|---|---|---|
| 1 | PROPAGATION_REQUIRED | 如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。 |
| 2 | PROPAGATION_SUPPORTS | 支持当前事务，如果当前没有事务，就以非事务方式执行 |
| 3 | PROPAGATION_MANDATORY | 使用当前的事务，如果当前没有事务，就抛出异常。 |
| 4 | PROPAGATION_REQUIRES_NEW | 新建事务，如果当前存在事务，把当前事务挂起。 |
| 5 | PROPAGATION_NOT_SUPPORTED | 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 |
| 6 | PROPAGATION_NEVER | 以非事务方式执行，如果当前存在事务，则抛出异常。 |
| 7 | PROPAGATION_NESTED | 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。 |
可以看出1、2、3为一组，都表现对当前事务的支持，不同的在于当前不存在事务的处理方式；4、5、6为一组，都表现对当前事务的不支持，不同的在于当前有事务的处理方式。然后7单独一组。
举个小栗子，比如有一个service中有方法A，调用了方法B，方法B的传播行为是PROPAGATION_REQUIRED，那么如果方法A的传播行为也是PROPAGATION_REQUIRED，方法A运行的时候，开启了一个事务，方法A中执行到方法B的时候，察觉到当前已经有事务了，方法B就不会再创建新的事务，直接包含在方法A的事务当中。
<tx:advice id="txAdvice">
<tx:attributes>
<tx:method name="get*" read-only="true" isolation="READ_COMMITTED" propagation="REQUIRES_NEW"/>
<tx:method name="find*" read-only="true"/>
<tx:method name="select*" read-only="true"/>
<tx:method name="count*" read-only="true"/>
<tx:method name="*" rollback-for="Exception"/>
</tx:attributes>
</tx:advice>
<tx:annotation-driven/>
<!--由于没有给method配置isolation属性，所以默认是isolation=‘DEFAULT’，也就是使用后端数据库默认的隔离级别。-->
网友评论