SQL2005中的事务与锁定

SQL2005中的事务与锁定

　终于定下心来写这个事务与锁定的文章，下笔后才发现真的很难写，交易中事务与锁定这个话题过于复杂，甚至有些还摸不着（就是通过DMV或DMF或其它工具你可能很难看到它的踪影），让人有点让人望而止步，但是既然说了要写，似乎不继续下去不是我的风格。在接下来的几篇文章（其实我也不知道要几篇）里我就事务与锁定这个话题写写，由SQL2005的并发模型引入事务，在事务的概念里展开锁定，本着先概念后实例的原则，和大家一起来学习，有不当之处希望大家指正。



     

一、并发及并发控制模型

　　对于这个我在 < < SQL2005数据库引擎结构>>一文有所提及，你可以通过如下链接进行访问：SQL2005数据库引擎结构（三）

并有一起的意思，显然就是多个的意思啦，光书面来理解并发就是多个东西同时发生，在数据库并发就是多个进程同时取、存数据库里数据的能力。着眼我们开发的系统，当然是激动态的并互不打架的并发用户进程越多并发能力就越强大啦，你想想看好多的网上购物系统，如果没有并发处理的能力，那么在上面登记的用户信息、商品有库存信息及用户帐户信息很难保证正确性和一致性，比如一个物品本身库存只有100个，结果如果100人同时在线进行预定，库存就有可能搞一个100－1的效果出来。

　　很显然对上述的例子我们希望一个进程在修改库存数据时必须阻止其它进程读或修改数据，或是正在读的用户进程限制其它活动的用户进程进行读或修改的操作，这样一来势必造成系统的并发性能下降，但是如果不采用这种办法又无法保证数据正确性和一致性。那怎么解决这个问题呢，办法只有通过不同的并发模式来管理这些并发事件。我们下面来理解并发控制的模式、并发下可能发生的非一致数据行为，即并发副作用，并由模式及数据行为引入事务及相关的5个隔离等级等概念，进而来理解不同隔离等级下并发实现的机理，显然我们自己也就可以回答上面这个问题了。
。。。。。。
。。。。。。
。。。。。。
二、并发下可能发生的并发副作用：丢失更新、脏读、不可重复读、幻影。

　　为了把这些可能发生的并发副作用说清楚，我们先“布置”一个场景：这是一个卖工艺石头的小商店，平时在前场完成交易，客户凭单据到后场领取石头，AMM和BMM是营业员，她们平时掌握库存数是通过大厅里的一块LED显示牌得之，并且在各自完成一笔交易后修改LED显示，以保证数据的实时性。在这个场景下我们来观察可能发生的行为：

1、  丢失更新：

　　丢失更新估计是所有数据库用户都不想发生的情况，什么是丢失更新呢？丢失更新是当2个或两个以上的用户进程同时读取同样的数据后又企图修改原来的数据时就会发生。好在上述场景下，大厅LED显示牌显示当前库存1000，这时同时有两个客户上门了，AMM和BMM满面春风接待，比如AMM卖出1个......