事务隔离级别

原子性、一致性、隔离性、持久性
(1) 原子性
 事务的原子性指的是，事务中包含的程序作为数据库的逻辑工作单位，它所做的对数据修改操作要么全部执行，要么完全不执行。这种特性称为原子性。
 事务的原子性要求，如果把一个事务可看作是一个程序，它要么完整的被执行，要么完全不执行。就是说事务的操纵序列或者完全应用到数据库或者完全不影响数据库。这种特性称为原子性。
　 假如用户在一个事务内完成了对数据库的更新，这时所有的更新对外部世界必须是可见的，或者完全没有更新。前者称事务已提交，后者称事务撤消（或流产）。DBMS必须确保由成功提交的事务完成的所有操纵在数据库内有完全的反映，而失败的事务对数据库完全没有影响。

(2) 一致性
    事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。这种特性称为事务的一致性。假如数据库的状态满足所有的完整性约束，就说该数据库是一致的。
一致性处理数据库中对所有语义约束的保护。假如数据库的状态满足所有的完整性约束，就说该数据库是一致的。例如，当数据库处于一致性状态S1时，对数据库执行一个事务，在事务执行期间假定数据库的状态是不一致的，当事务执行结束时，数据库处在一致性状态S2。

(3) 隔离性
隔离性指并发的事务是相互隔离的。即一个事务内部的操作及正在操作的数据必须封锁起来，不被其它企图进行修改的事务看到。
　　隔离性是DBMS针对并发事务间的冲突提供的安全保证。DBMS可以通过加锁在并发执行的事务间提供不同级别的分离。假如并发交叉执行的事务没有任何控制，操纵相同的共享对象的多个并发事务的执行可能引起异常情况。
DBMS可以在并发执行的事务间提供不同级别的隔离。隔离的级别和并发事务的吞吐量之间存在反比关系。较多事务的可隔离性可能会带来较高的冲突和较多的事务流产。流产的事务要消耗资源，这些资源必须要重新被访问。因此，确保高分离级别的DBMS需要更多的开销。

(4)持久性
持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。即一旦一个事务提交，DBMS保证它对数据库中数据的改变应该是永久性的，耐得住任何系统故障。持久性通过数据库备份和恢复来保证。
持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。即对已提交事务的更新能恢复。一旦一个事务被提交，DBMS必须保证提供适当的冗余，使其耐得住系统的故障。所以，持久性主要在于DBMS的恢复性能。

 

设置事务隔离性级别
     1)幻读：事务1读取记录时事务2增加了记录并提交，事务1再次读取时可以看到事务2新增的记录；
     2)不可重复读取：事务1读取记录时，事务2更新了记录并提交，事务1再次读取时可以看到事务2修改后的记录；
     3)脏读：事务1更新了记录，但没有提交，事务2读取了更新后的行，然后事务T1回滚，现在T2读取无效。
     事务隔离级别描述：
     READ UNCOMMITTED：幻读，不可重复读和脏读均允许；
     READ COMMITTED：允许幻读和不可重复读，但不允许脏读；
     REPEATABLE READ：允许幻读，但不允许不可重复读和脏读；
     SERIALIZABLE:幻读，不可重复读和脏读都不允许
     ORACLE默认的是 READ COMMITTED
     设置语法：
      SET TRANSACTION ISOLATION LEVEL SERIALIZABLE|READ COMMITTED|READ UNCOMMITTED|REPEATABLE READ；

 

spring 中一共定义了六种事务传播属性, 如果你觉得看起来不够直观, 那么我来转贴一个满大街都有的翻译
　　引用
　PROPAGATION_REQUIRED -- 支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
　PROPAGATION_SUPPORTS -- 支持当前事务，如果当前没有事务，就以非事务方式执行。
　PROPAGATION_MANDATORY -- 支持当前事务，如果当前没有事务，就抛出异常。
　PROPAGATION_REQUIRES_NEW -- 新建事务，如果当前存在事务，把当前事务挂起。
　PROPAGATION_NOT_SUPPORTED -- 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
　PROPAGATION_NEVER -- 以非事务方式执行，如果当前存在事务，则抛出异常。
　PROPAGATION_NESTED -- 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。

　　前六个策略类似于EJB CMT，第七个（PROPAGATION_NESTED）是Spring所提供的一个特殊变量。
　　它要求事务管理器或者使用JDBC 3.0 Savepoint API提供嵌套事务行为（如Spring的DataSourceTransactionManager）
　　在我所见过的误解中, 最常见的是下面这种:

引用
　　假如有两个业务接口 ServiceA 和 ServiceB, 其中 ServiceA 中有一个方法实现如下
　　/**
　　* 事务属性配置为 PROPAGATION_REQUIRED
　　*/
　　void methodA() {
　　// 调用 ServiceB 的方法
　　ServiceB.methodB();
　　}
　　那么如果 ServiceB 的 methodB 如果配置了事务, 就必须配置为 PROPAGATION_NESTED
　　这种想法可能害了不少人, 认为 Service 之间应该避免互相调用, 其实根本不用担心这点，PROPAGATION_REQUIRED 已经说得很明白,
　　如果当前线程中已经存在事务, 方法调用会加入此事务, 果当前没有事务，就新建一个事务, 所以 ServiceB#methodB() 的事务只要遵循最普通的规则配置为 PROPAGATION_REQUIRED 即可, 如果 ServiceB#methodB (我们称之为内部事务, 为下文打下基础) 抛了异常, 那么 ServiceA#methodA(我们称之为外部事务) 如果没有特殊配置此异常时事务提交 (即 +MyCheckedException的用法), 那么整个事务是一定要 rollback 的, 什么 Service 只能调 Dao 之类的言论纯属无稽之谈, spring 只负责配置了事务属性方法的拦截, 它怎么知道你这个方法是在 Service 还是 Dao 里 ?

也就是说, 最容易弄混淆的其实是 PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED, 那么这两种方式又有何区别呢? 我简单的翻译一下 Juergen Hoeller 的话 :
　　PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 "内部" 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行.
　　另一方面, PROPAGATION_NESTED 开始一个 "嵌套的" 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交.
　　由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 如果外部事务 commit, 潜套事务也会被 commit, 这个规则同样适用于 roll back.

 

1        事务隔离

事务隔离是数据库提供的功能。

SQL Server通过SET TRANSACTION ISOLATION LEVEL语句设置事务隔离级别：

SET TRANSACTION ISOLATION LEVEL

    { READ UNCOMMITTED

    | READ COMMITTED

    | REPEATABLE READ

    | SNAPSHOT

    | SERIALIZABLE

    }

[ ; ]

Read Committed是SQL Server的预设隔离等级。
1.1         READ UNCOMMITTED

Read UnCommitted事务可以读取事务已修改，但未提交的的记录。

Read UnCommitted事务会产生脏读（Dirty Read）。

Read UnCommitted事务与select语句加nolock的效果一样，它是所有隔离级别中限制最少的。
1.2         READ COMMITTED

Read Committed事务不能读取事务已修改，但未提交的记录。

Read Committed是SQL Server的预设隔离等级。
1.3         REPEATABLE READ

Repeatable Read事务不能读取交易已修改，但未提交的记录，并且在事务完成之前，任何其它事务都不能修改目前事务已读取的记录。

其它事务仍可以插入新记录，但必须符合当前事务的搜索条件——这意味着当前事务重新查询记录时，会产生幻读（Phantom Read）。
1.4         SNAPSHOT

Snapshot事务中任何语句所读取的记录，都是事务启动时的数据。

这相当于事务启动时，数据库为事务生成了一份专用“快照”。

在当前事务中看到不其它事务在当前事务启动之后所进行的数据修改。

Snapshot事务不会读取记录时要求锁定，读取记录的Snapshot事务不会锁住其它事务写入记录，写入记录的事务也不会锁住Snapshot事务读取数据。
1.5         SERIALIZABLE

Serializable事务会产生以下效果：

1.语句无法读取其它事务已修改但未提交的记录。

2.在当前事务完成之前，其它事务不能修改目前事务已读取的记录。

3.在当前事务完成之前，其它事务所插入的新记录，其索引键值不能在当前事务的任何语句所读取的索引键范围中。

Serializable事务与select语句加holdlock的效果一样。
2        READ COMMITTED 和 REPEATABLE READ

Read Committed 和 Repeatable Read 是最常用的两种事务。

Read Committed 是 SQL Server的默认级别；而 Repeatable Read 比Read Committed 更能保证数据一致性。
2.1         特点

Read Committed会阻塞其它事务中的update，但不会阻塞select。

Repeatable Read不但会阻塞其它事务中的update，还会阻塞select。

 

Read Committed 和 Repeatable Read 的相同点是：都会阻塞其它事务的update语句。

Read Committed 和 Repeatable Read 的不同点是：Read Committed 不会阻塞其它事务的select语句，但Repeatable Read阻塞。

 

注意，Read Committed 和 Repeatable Read 都是行级锁，它们只会锁住与自己相关的记录。当事务提交之后，阻塞的语句就会继续执行。
2.2         理解
2.2.1     READ COMMITTED

Read Committed 事务的含义是我select出来的记录，别人只能看，不能改（只阻塞别的事务的update）。

 

Read Committed 的缺点是：无法防止读取不一致和修改丢失。

读取不一致是因为Read Committed 不锁住读取的记录；修改丢失是因为别的事务也能读取当前事务的记录，虽然会阻塞别的事务的update，但在当前事务提交之后，别的事务的update语句会继续执行，进而覆盖上一次事务的结果，导致上一次的修改丢失。
2.2.2     REPEATABLE READ

Repeatable Read 事务的含义是我select出来的记录，不允许别人看，也不允许别人改（阻塞别的事务select、update），这就意味着我可以在事务中多次select数据，而不用担心出现“脏读”——这就是“可重复读取”的意思。

 

Repeatable Read 虽然解决了Read Committed 事务的读取不一致和修改丢失的缺点，但它也有缺点（尽管这个缺点Read Committed 也有）：

Repeatable Read 不会阻塞insert和delete，所以会出现“幻读”—— 两次select的结果不一样。还有，Repeatable Read 占用的资源比Read Committed 大。
3        在应用程序中设置事务隔离级别

READ COMMITTED 是 Microsoft SQL Server Database Engine 的预设隔离等级。

 

已指定隔离等级时，在 SQL Server 工作阶段中，所有查询和数据操作语言 (DML) 陈述式的锁定行为都会在此隔离等级运作。此隔离等级会维持有效，直到工作阶段结束或隔离等级设为另一个等级为止。

 

如果应用程序必须在不同隔离等级操作，可以使用下列方法来设定隔离等级：

 

l           执行 SET TRANSACTION ISOLATION LEVEL Transact-SQL 陈述式。

 

l           如果 ADO.NET 应用程序使用 System.Data.SqlClient 管理的命名空间，可以使用 SqlConnection.BeginTransaction 方法来指定 IsolationLevel 选项。

 

l           使用 ADO 的应用程序可以设定 Autocommit Isolation Levels 属性。

 

l           当启动交易时，使用 OLE DB 的应用程序可以将 isoLevel 设为所要的交易隔离等级，以呼叫 ITransactionLocal::StartTransaction。当在自动认可模式中指定隔离等级时，使用 OLE DB 的应用程序可以将 DBPROPSET_SESSION 属性 DBPROP_SESS_AUTOCOMMITISOLEVELS 设为所要的交易隔离等级。

 

l           使用 ODBC 的应用程序可以使用 SQLSetConnectAttr 来设定 SQL_COPT_SS_TXN_ISOLATION 属性。
4        悲观锁

悲观锁是指假设并发更新冲突会发生，所以不管冲突是否真的发生，都会使用锁机制。

 

悲观锁会完成以下功能：锁住读取的记录，防止其它事务读取和更新这些记录。其它事务会一直阻塞，直到这个事务结束。

 

悲观锁是在使用了数据库的事务隔离功能的基础上，独享占用的资源，以此保证读取数据一致性，避免修改丢失。

 

悲观锁可以使用Repeatable Read事务，它完全满足悲观锁的要求。
5        乐观锁

乐观锁不会锁住任何东西，也就是说，它不依赖数据库的事务机制，乐观锁完全是应用系统层面的东西。

如果使用乐观锁，那么数据库就必须加版本字段，否则就只能比较所有字段，但因为浮点类型不能比较，所以实际上没有版本字段是不可行的。
6        死锁

当二或多个工作各自具有某个资源的锁定，但其它工作尝试要锁定此资源，而造成工作永久封锁彼此时，会发生死锁。例如：

1.           事务 A 取得数据列 1 的共享锁定。

2.           事务B 取得数据列 2 的共享锁定。

3.           事务A 现在要求数据列 2 的独占锁定，但会被封锁直到事务B 完成并释出对数据列 2 的共享锁定为止。

4.           事务B 现在要求数据列 1 的独占锁定，但会被封锁直到事务A 完成并释出对数据列 1 的共享锁定为止。

等到事务B 完成后，事务A 才能完成，但事务B 被事务A 封锁了。这个状况也称为「循环相依性」(Cyclic Dependency)。事务A 相依于事务B，并且事务B 也因为相依于事务A 而封闭了这个循环。

 

例如以下操作就会产生死锁，两个连接互相阻塞对方的update。

 

连接1：

begin tran

select * from customers

update customers set CompanyName = CompanyName

 

waitfor delay '00:00:05'

 

select * from Employees

–因为Employees被连接2锁住了，所以这里会阻塞。

update Employees set LastName = LastName

commit tran

 

连接2：

begin tran

select * from Employees

update Employees set LastName = LastName

 

waitfor delay '00:00:05'

 

select * from customers

--因为customers被连接1锁住了，所以这里会阻塞。

update customers set CompanyName = CompanyName

commit tran

 

SQL Server遇到死锁时会自动杀死其中一个事务，而另一个事务会正常结束（提交或回滚）。

SQL Server对杀死的连接返回错误代码是1205，异常提示是：

Your transaction (process ID #52) was deadlocked on {lock | communication buffer | thRead} resources with another process and has been chosen as the deadlock victim. Rerun your transaction.

 
除了Read UnCommitted和Snapshot，其它类型的事务都可能产生死锁。