数据库事物

1. 事物的隔离级别
- 事物的五种隔离级别
TRANSACTION_NONE 不使用事务。
TRANSACTION_READ_UNCOMMITTED 允许脏读。
TRANSACTION_READ_COMMITTED 防止脏读，最常用的隔离级别,并且是大多数数据库的默认隔离级别
TRANSACTION_REPEATABLE_READ 可以防止脏读和不可重复读，
TRANSACTION_SERIALIZABLE 可以防止脏读，不可重复读取和幻读，（事务串行化）会降低数据库的效率
事物的隔离级别越高，数据库的性能消耗越大，根据需求选择合适的事物。

脏读：一个事务读取到了另外一个事务没有提交的数据
脏读就是指:当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。
事物级别是TRANSACTION_READ_COMMITTED或者以上，可防止脏读。

不可重复读：在同一事务中，两次读取同一数据，得到内容不同
*此时事务1对同一数据查询了两次，可得到的内容不同，称为不可重复读
事物级别是TRANSACTION_REPEATABLE_READ或者以上 ，可防止不可重复读。

幻读：同一事务中，用同样的操作读取两次，得到的记录数不相同
幻读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，
这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表
中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，
就好象发生了幻觉一样。
事物级别是TRANSACTION_SERIALIZABLE ，可以防止幻读。

设置事物的隔离级别：
SET TRANSACTION ISOLATION LEVEL [READ COMMITED | SERIALIZABLE | READ ONLY];
Mysql InnoDB引擎的事物隔离级别：
– 获取全局隔离级别
SELECT @@global.tx_isolation;
–获取会话隔离级别
SELECT @@tx_isolation;
–全局隔离级别设置
SET GLOBAL TRANSACTION ISOLATION LEVEL [
READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE];
–会话隔离级别设置
SET SESSION TRANSACTION ISOLATION LEVEL [
READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE];

2. 锁的两种分类
（1）从数据库系统的角度来看，锁分为以下三种类型：
独占锁（Exclusive Lock）
独占锁锁定的资源只允许进行锁定操作的程序使用，其它任何对它的操作均不会被接受。执行数据更新命令，即INSERT、 UPDATE 或DELETE 命令时，SQL Server 会自动使用独占锁。但当对象上有其它锁存在时，无法对其加独占锁。独占锁一直到事务结束才能被释放。
共享锁（Shared Lock）
共享锁锁定的资源可以被其它用户读取，但其它用户不能修改它。在SELECT 命令执行时，SQL Server 通常会对对象进行共享锁锁定。通常加共享锁的数据页被读取完毕后，共享锁就会立即被释放。
更新锁（Update Lock）
更新锁是为了防止死锁而设立的。当SQL Server 准备更新数据时，它首先对数据对象作更新锁锁定，这样数据将不能被修改，但可以读取。等到SQL Server 确定要进行更新数据操作时，它会自动将更新锁换为独占锁。但当对象上有其它锁存在时，无法对其作更新锁锁定。
（2）从程序员的角度看，锁分为以下两种类型：
悲观锁（Pessimistic Lock）
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
乐观锁（Optimistic Lock）
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

3. 事物的传播特性
Propagation ：　　key属性确定代理应该给哪个方法增加事务行为。这样的属性最重要的部份是传播行为。
有以下选项可供使用：PROPAGATION_REQUIRED–支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS–支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY–支持当前事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW–新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED–以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER–以非事务方式执行，如果当前存在事务，则抛出异常。
解释：
1： PROPAGATION_REQUIRED
方法A.B都有事务，且B定义了这个属性，运行A时候调用了B，如果A要回滚则B即使已经提交了事务也要回滚。
2： PROPAGATION_SUPPORTS
如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行
3： PROPAGATION_MANDATORY
必须在一个事务中运行。也就是说，他只能被一个父事务调用。否则，他就要抛出异常
4： PROPAGATION_REQUIRES_NEW
A.B两个事务，A声明为PROPAGATION_REQUIRED，B声明为PROPAGATION_REQUIRES_NEW。执行B的时候A方法的事务会挂起，B创建一个新的事务等待B的完成以后才会执行A。
区别在于事务的回滚：如果B提交了，A失败只有A回滚，B不会回滚。如果B失败了，B回滚，A会捕获异常，A事务任然可能提交。
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的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。