事务的隔离级别及传播特性

      事务的隔离级别及传播特性

       数据库的事务隔离级别（TRANSACTION ISOLATION LEVEL）是一个数据库上很基本的一个概念。为什么会有事务隔离级别，SQL Server上实现了哪些事务隔离级别？事务隔离级别的 前提是一个 多用户、多进程、多线程的并发系统 ，在这个系统中为了保证数据的一致性和完整性 ，我们 引入了事务隔离级别 这个概念，对一个单用户、单线程的应用来说则不存在这个问题。

    为了避免上述几种事务之间的影响，SQL Server通过设置不同的隔离级别来进行不同程度的避免。因为高的隔离等级意味着更多的锁，从而牺牲性能。所以这个选项开放给了用户根据具体的需求进行设置。不过 默认的隔离级别Read Commited 符合了多数的实际需求.

   SQL Server 隔离事务之间的影响是 通过锁来实现 的，通过阻塞来阻止上述影响 。 不同的隔离级别是通过加不同的锁，造成阻塞来实现的，所以会以付出性能作为代价 ； 安全级别越高，处理效率越低；安全级别越低，效率高。这四个级别可以 逐一解决脏读，不可重复读，幻读的问题。

       使用方法：SET TRANSACTIONISOLATION LEVEL REPEATABLE READ

        未提交读：  在读数据时 不会检查或使用任何锁 。因此，在这种隔离级别中可能读取到没有提交的数据。  

        已提交读： 只读取提交的数据并等待其他事务 释放排他锁。 读数据的 共享锁 在读操作完成后立即释放 。已提交读是SQL Server的默认隔离级别。 

        可重复读：  像已提交读级别那样读数据，但 会保持共享锁直到事务结束 。  

        可串行读（序列化）： 工作方式类似于可重复读。但它 不仅会锁定受影响的数据，还会锁定这个范围。 这就阻止了新数据插入查询所涉及的范围。

-----------------------------------------------------------------------------------------------------------------------------------------------

1. read uncommited：是最低的事务隔离级别，它允许另外一个事务可以看到这个事务未提交的数据。
2. read commited：保证一个事物提交后才能被另外一个事务读取。另外一个事务不能读取该事物未提交的数据。
3. repeatable read：这种事务隔离级别可以防止脏读，不可重复读。但是可能会出现幻象读。它除了保证一个事务不能被另外一个事务读取未提交的数据之外还避免了以下情况产生（不可重复读）。
4. serializable：这是花费最高代价但最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读之外，还避免了幻象读。
5. 脏读、不可重复读、幻象读概念说明：

• 脏读：指当一个事务正字访问数据，并且对数据进行了修改，而这种数据还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据还没有提交那么另外一个事务读取到的这个数据我们称之为脏数据。依据脏数据所做的操作肯能是不正确的。
• 不可重复读：指在一个事务内，多次读同一数据。在这个事务还没有执行结束，另外一个事务也访问该同一数据，那么在第一个事务中的两次读取数据之间，由于第二个事务的修改第一个事务两次读到的数据可能是不一样的，这样就发生了在一个事物内两次连续读到的数据是不一样的，这种情况被称为是不可重复读。
• 幻象读：一个事务先后读取一个范围的记录，但两次读取的纪录数不同，我们称之为幻象读（两次执行同一条 select 语句会出现不同的结果，第二次读会增加一数据行，并没有说这两次执行是在同一个事务中）

spring事务传播特性：

事务传播行为就是多个事务方法相互调用时，事务如何在这些方法间传播。spring支持7种事务传播行为：

• propagation_requierd：如果当前没有事务，就新建一个事务，如果已存在一个事务中，加入到这个事务中，这是最常见的选择。
• propagation_supports：支持当前事务，如果没有当前事务，就以非事务方法执行。
• propagation_mandatory：使用当前事务，如果没有当前事务，就抛出异常。
• propagation_required_new：新建事务，如果当前存在事务，把当前事务挂起。
• propagation_not_supported：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
• propagation_never：以非事务方式执行操作，如果当前事务存在则抛出异常。
• propagation_nested：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与propagation_required类似的操作

Spring 默认的事务传播行为是 PROPAGATION_REQUIRED，它适合于绝大多数的情况。假设 ServiveX#methodX() 都工作在事务环境下（即都被 Spring 事务增强了），假设程序中存在如下的调用链：Service1#method1()->Service2#method2()->Service3#method3()，那么这 3 个服务类的 3 个方法通过 Spring 的事务传播机制都工作在同一个事务中。

参考：http://kljjack.iteye.com/blog/1949093