-----------------------------------------------------------------------
-- Author : HappyFlyStone
-- Date : 2009-09-24 21:36:30
-- Version: Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86)
-- Apr 14 2006 01:12:25
-- Copyright (c) 1988-2005 Microsoft Corporation
-- Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
-- 转载请注明出处，更多请关注：http://blog.csdn.net/happyflystone
-- 关键字：LOCK Concurrency 锁 事务 并发
------------------------------------------------------------------------
终于定下心来写这个事务与锁定的文章，下笔后才发现真的很难写，交易中事务与锁定这个话题过于复杂，甚至有些还摸不着（就是通过DMV或DMF或其它工具你可能很难看到它的踪影），让人有点让人望而止步，但是既然说了要写，似乎不继续下去不是我的风格。在接下来的几篇文章（其实我也不知道要几篇）里我就事务与锁定这个话题写写，由SQL2005的并发模型引入事务，在事务的概念里展开锁定，本着先概念后实例的原则，和大家一起来学习，有不当之处希望大家指正。
一、并发及并发控制模型
对于这个我在<< SQL2005数据库引擎结构>>一文有所提及，你可以通过如下链接进行访问：SQL2005数据库引擎结构（三）
并有一起的意思，显然就是多个的意思啦，光书面来理解并发就是多个东西同时发生，在数据库并发就是多个进程同时取、存数据库里数据的能力。着眼我们开发的系统，当然是激动态的并互不打架的并发用户进程越多并发能力就越强大啦，你想想看好多的网上购物系统，如果没有并发处理的能力，那么在上面登记的用户信息、商品有库存信息及用户帐户信息很难保证正确性和一致性，比如一个物品本身库存只有100个，结果如果100人同时在线进行预定，库存就有可能搞一个100－1的效果出来。
很显然对上述的例子我们希望一个进程在修改库存数据时必须阻止其它进程读或修改数据，或是正在读的用户进程限制其它活动的用户进程进行读或修改的操作，这样一来势必造成系统的并发性能下降，但是如果不采用这种办法又无法保证数据正确性和一致性。那怎么解决这个问题呢，办法只有通过不同的并发模式来管理这些并发事件。我们下面来理解并发控制的模式、并发下可能发生的非一致数据行为，即并发副作用，并由模式及数据行为引入事务及相关的5个隔离等级等概念，进而来理解不同隔离等级下并发实现的机理，显然我们自己也就可以回答上面这个问题了。
并发控制模式：一般并发控制模式有两种：积极并发（又称乐观并发）和消极并发（又称悲观并发）。积极并发是SQL2005才引入的新模式，在2005以前的版本其实只有唯一的并发模式即：消极并发。那什么是消极并发呢？消极并发就是SQLSERVER默认行为是进程以获取锁的方式来阻止其它进程对正在使用的数据进行修改的能力。对于数据库来说对数据修改的操作进程肯定很多，这些进程肯定都会去影响其它进程读取数据的能力，反之，对数据进行读时加上锁也一定会影响其它进程修改数据的能力，简而言之，就是读取与修改数据之间是冲突的、互相阻塞的。乐观并发是SQL2005利用一个行版本控制器的新技术来处理上述的冲突。行版本控制器在当前进程读取数据时生成旧版本的数据，使得其它请求读的进程能看到当前进程一开始读取时的数据状态，并且不受当前进程或其它进程对数据进行修改的影响。简而言之读与修改之间是不冲突的，但是修改与修改之间还是冲突的。
对于这两种并发模式两个进程同时请求数据修改必然会冲突的，除此以外的差别在于一个是在冲突发生前进行控制，另一个在冲突发生了进行协调处理。这好比生活一样，两种方式就是两种不同的人生，一种消极怠工一种积极向上。
二、并发下可能发生的并发副作用：丢失更新、脏读、不可重复读、幻影。
为了把这些可能发生的并发副作用说清楚，我们先“布置”一个场景：这是一个卖工艺石头的小商店，平时在前场完成交易，客户凭单据到后场领取石头，AMM和BMM是营业员，她们平时掌握库存数是通过大厅里的一块LED显示牌得之，并且在各自完成一笔交易后修改LED显示，以保证数据的实时性。在这个场景下我们来观察可能发生的行为：
1、 丢失更新：
丢失更新估计是所有数据库用户都不想发生的情况，什么是丢失更新呢？丢失更新是当2个或两个以上的用户进程同时读取同样的数据后又企图修改原来的数据时就会发生。好在上述场景下，大厅LED显示牌显示当前库存1000，这时同时有两个客户上门了，AMM和BMM满面春风接待，比如AMM卖出1个，BMM呢卖出了10个，AMM处理完业务后赶紧把LED显示数修改为1000 － 1 ＝ 999个，几乎同一时间BMM处理完自己的业务后习惯性的把LED显示数修改为1000 － 10 ＝ 990 个，这时老板从后场过来，看着LED有点不爽，大吼一声：现在还有多少存货呀？，AMM说我卖了1个，BMM说我是10个，不过两个人都傻眼了，LED显示怎么是990呢？原来BMM在更改时把AMM做的更改搞丢了，这就是丢失更新。显然对老板和营业员来说都是必须回避不能发生的事。
2、 脏读
很显然，在上面的例子里因为AMM和BMM事先因为不知道对方已经修改了柜台存货，所以才造成了存货数目显示错误，出了问题我们要想办法解决问题，英明的老板说了，你们随便哪个在谈一笔生意时先把客户意向购卖石头数扣掉，如果最后客户不要你再改回头，两个MM对老板的英明决定表示等赞同，可是问题还是发生了，怎么回事呢，还是假设柜台存货1000个石头，AMM有一笔生意正在谈着，顾客意向要600块石头，AMM赶紧把LED显示修改为400。这时BMM也很兴奋因为她已经谈成一笔700块石头的生意，所以呢BMM抬头一看，好嘛，还有400块可卖，完了BMM的生意做不成了，只好向客户表达歉意。BMM只能让老板进货，可是老板一看LED显示还有1000块怎么你的700块生意做不成了呢？哦，因为最后AMM的600块生意没做成。嘿嘿，也就是BMM错误的读取了AMM修改的数据，完成了一次“脏读”操作。脏读也就是一个用户进程读取了另一个用户进程修改过但没有正式提交的数据，这时导致了数据不一样的情形发生了。因为A用户进程是无法确认另一个B用户进程在自己提交数据前是否修改过数据，这是数据库系统默认情况下必须回避的。
3、 不可重复读
不可重复读又称不一致分析，不过，个人以为似乎不一致分析更让人好理解一点，但是大部分地方称不可重复读。不可重复读是指一个用户进程两次读取数据得到不同样的数据。比如那个英明的老板吧，他知道要盘点，掌握库存的变化，忙得満头大汗，终于计出库存数来，比如说1000吧，或是当他跑到大厅一看LED显示牌却只有了900，显然这一次的检查库存的过程中两次得到库存数不一样，原因就是AMM在老板从后场走到前场的过程中做了一担生意，卖出100块。嘿嘿，老板气又不是不气又不是，这AMM真可爱，做生意挺两下呀！显然在一个用户进程两次读取数据间隔内另一个用户进程修改了数据，这就是不可重复读。
4、 幻影
幻影，嘿嘿，我们不是经常无视BS自己的人吗？你无视他并不代表他不BS你吧，这个BS你的人就成了幻影，嘿嘿开个玩笑。这种情况多数在查询带谓词时结果集内部分数据变化的时候发生，如果谓词限定下在一个交易里两次同一查询的结果集不同，那些不同的行或行集就是幻影。比方说英明的老板到大厅走走，顺便请大家吃饭，数数人数，BMM，。。。。一路数过去，发现有10人，呵呵，正好一桌，，通知好她们后老板回办会室拿人民币，回到前场看见AMM，再一数11人，晕，刚才怎么看到AMM ？AMM也知道了老板请客没数到他，很是生气，这时AMM就成了幻影。
以上是四种并发副作用只是一个交易事务里或事务间可能发生的异常的非一致的数据行为（记好并发副作用和不一致的数据行为术语，这在以后会经常提及），其实还是有好多的行为是我们所期望的，那么我们期望的行为是什么呢，下面我们在事务里来介绍。我们可以通过隔离级别来设定一个合适级别以决定上述上种数据行为哪些是允许的。那什么是交易事务，什么又是隔离等级呢？
三、事务
事务是数据库一笔交易的基本单元，存于两种并发模型中。又分为显式事务和隐式事务。显式事务是显式的开始一个事务并显式的滚回或提交事务，除了显式的事务还有隐式的了，隐式事务是数据库自己根据情况完成的事务处理，如单独的select、update、delete、select语句。
作为一个事务，它能保证数据库的数据一致性及重做。提到事务不得不提及事务的ACID属性：原子性、一致性、隔离性及持久性。不管是显式还是隐式的，都必须维持这四个属性。
原子性：一个事务是一个整体，要不全部提交，要不全部中止。意思就是要不全部成功提交到数据，要不全部回滚恢复事务开始前的状态。比方我们做一个入库操作，在这个事务里，审核入库单和修改库存作为一个整体，要不单据变成审核过同时库存增加相应的值，要不就是单据未审核同时库存不变。
一致性：一致性要求事务保证数据在逻辑上正确，处理的结果不是一个不确定的状态，什么是不确定状态呢，比如说我们完成一个库存减少的操作，如果没有一个出货单据那么这个库存的当前修改就是一个不确定状态，因为你无法知道减少的东东到哪儿去了。
隔离性：这个隔离和锁定有关，以后在说锁的过程中会提到这些，你先记住这个就行。
持久性：持久很显然是要求正确提交的修改必须保证长久存在，不会因为关机或掉电把这笔交易丢掉。进行中的事务发生故障那事务就完全撤销，像没有发生一样，如果事务提交的确认已经反馈给应用程序发生故障，那么这些日志利用先写技术，在启动恢复阶段自动完成相应的动作保证事务的持久性。（这个在前面的引擎组件有过介绍哦。）
今天的任务完成，请大家继续关注我的blog: http://blog.csdn.net/happyflystone