对事务的一些整理

1.什么是事务

简单例子：银行有客户A和客户B,A和B的账号里都有1000元，现在A要向B转账500，这时候你就有两个操作，A账号减500，B账户+500，这是一起的，所以可以把这个过程称作事务。

2.事务的四大特征（事务必须要满足的条件）

a.原子性：简单来说就是要么一起成功，要么就一起失败然后数据回滚。比如A向B转账成功，B账号要添加时停电了，系统崩溃了，A账号变为了500元，但B账号还是1000元。这是不允许的结果。

b.一致性：是指数据库一个一致性状态变为另一个一致性状态，也就是一个事务在执行之前和执行之后都必须处于一致性状态。比如A和B总共有2000元，执行之后应该也有2000元。（这个地方我也是硬着头皮理解的，我觉得如果它破坏了原子性，这个一致性肯定也不满足，总结就是原子性包含了一致性，为什么还要有一致性，有懂的请下方留言告诫一下）

c.隔离性：这个是发生在并发情况下，比如多个用户操作同一张数据库表，甚至同一条记录，多个用户它就是多个事务，如果多个事务不隔离，它们就会互相干扰，得到错误的结果。事务1要么在事务2执行前执行，要么在事务2执行后执行，绝不能一会执行事务1，一会执行事务2。

d.持久性：一旦事务提交，所有修改的数据都会保存到数据库，数据不会再丢失。

3.并发情况下事务可能发生的问题，也就是隔离性可能产生的问题

a.脏读：是指一个事务读取了另一个未提交的事务数据。什么意思呢，比如A转账B这个操作事务1和B查看账户这个操作事务2，当事务1转账给B已成功，此时，事务2读取了这个结果确实是1500，但是事务1还没有提交，那么事务就不是持久性的，也就是没有保存起来，你读取的数据就是脏数据。

b.不可重复读：是指一个事务多次读取同一条数据，但读取结果不一样。比如还是A转账B这个操作事务1和B查看账户这个操作事务2，但这次我们B查看账户事务不只查看一次，这个事务包含两次查看。第一次查看，A还未转账，结果为1000，第二次查看，这时事务1提交了，转账成功，查看结果为1500，两次结果不一样，这就是不可重复读。和脏读相比，这次事务1是提交了，而且同一个事务中查看同个数据多次。

c.幻读：这个很好理解，比如事务1将某个表中的所有数据的某个列的值将1改为2，事务2呢向这个表插入一条新的数据，但修改列的值还是1，那么事务1和事务2都提交了，这时我们去查看表数据，发现还有一条数据值是1，是不是觉得很梦幻，如果不知道是由于幻读引起的，我觉得这个错误会让你怀疑人生。

4.针对于并发下事务可能发生的问题，数据库给出了4种隔离级别。

a.Read uncommited(读未提交)：最低级别，任何事情都可能发生

b.Read Commited(读已提交)：可避免脏读

c.Repeatable Read(可重复读):  可避免脏读，不可重复读

d.Serializable(串行化)：可避免脏读，不可重复读，幻读

从上可看出，串行化的级别最高，但是级别越高，就代表代价也会更高，性能最低。

5.直接使用数据库进行数据库隔离比较少，而是交给spring来处理，下面列出spring的事务隔离，其实差不多

DEFAULT 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别. 
未提交读（read uncommited） :脏读，不可重复读，虚读都有可能发生 
已提交读 （read commited）:避免脏读。但是不可重复读和虚读有可能发生 
可重复读 （repeatable read） :避免脏读和不可重复读.但是虚读有可能发生. 
串行化的 （serializable） :避免以上所有读问题. 
Mysql 默认:可重复读 
Oracle 默认:读已提交

6.事务的另一个概念，事务的传播性

怎么理解传播性，查看一些资料，我觉得就是如何定义是否同一个事务。在我们使用的hibernate框架中，很多都是在service层设置事务，那么service的一个方法就是一个事务，里面的各种sql语句要么一起成功，一起失败。如果一个service方法调用了另一个service方法，我们肯定是希望它们同处于同一个事务，否则怎么实现事务的一致性。（这就是上面的一致性所必须之处吗，好像很有道理）事务的传播性就是解决这个问题，就好像传播一样，从第一个service方法开始创建事务，其他的serivce方法沿用这个事务。（这只是其中的一种事务的传播设置，实际想要怎样的效果可自行设置）

7.spring的7中事务传播性

下面是直接抄过来的，讲的比较好。

1： PROPAGATION_REQUIRED 
加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务
比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，
         ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA
的事务内部，就不再起新的事务。而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。
这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。即使ServiceB.methodB的事务已经被
提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚

2：   PROPAGATION_SUPPORTS
如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行
这就跟平常用的普通非事务的代码只有一点点区别了。不理这个，因为我也没有觉得有什么区别

3：   PROPAGATION_MANDATORY
必须在一个事务中运行。也就是说，他只能被一个父事务调用。否则，他就要抛出异常。

4：   PROPAGATION_REQUIRES_NEW
这个就比较绕口了。 比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW，
那么当执行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起，ServiceB.methodB会起一个新的事务，等待ServiceB.methodB的事务完成以后，
他才继续执行。他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为ServiceB.methodB是新起一个事务，那么就是存在
两个不同的事务。如果ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚，ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚，
如果他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。

5：   PROPAGATION_NOT_SUPPORTED 
当前不支持事务。比如ServiceA.methodA的事务级别是PROPAGATION_REQUIRED ，而ServiceB.methodB的事务级别是PROPAGATION_NOT_SUPPORTED ，
那么当执行到ServiceB.methodB时，ServiceA.methodA的事务挂起，而他以非事务的状态运行完，再继续ServiceA.methodA的事务。

6：   PROPAGATION_NEVER 
不能在事务中运行。假设ServiceA.methodA的事务级别是PROPAGATION_REQUIRED， 而ServiceB.methodB的事务级别是PROPAGATION_NEVER ，
那么ServiceB.methodB就要抛出异常了。

7：   PROPAGATION_NESTED 
理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，将会与他的父事务相互独立，
而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。
而Nested事务的好处是他有一个savepoint。