读的时候可以共享锁
修改的时候排他锁
SQL Server自己会完成的。

解决方案 »

  1.   

    锁是由软件使用的对象,用于表明用户与资源有某种相关性。软件不允许其它用户在资源上执行将对拥有锁的用户的相关性产生负面影响的操作。锁由系统软件在内部管理,并基于用户所执行的操作被获取和释放。Microsoft® SQL Server™ 2000 使用锁在多个同时在数据库内执行修改的用户间实现悲观并发控制。默认情况下,SQL Server 基于每个连接管理事务和锁。例如,如果应用程序打开两个 SQL Server 连接,由一个连接获取的锁不能与另一个连接共享。两个连接都不能获取将与另一个连接所控制的锁冲突的锁。只有绑定连接不受该规则的影响。有关更多信息,请参见使用绑定连接。 SQL Server 锁在数据库内的不同粒度级别上应用。可以为行、页、键、键范围、索引、表或数据库获取锁。SQL Server 动态确定每个 Transact-SQL 语句的锁的适当的放置级别。获取锁的级别可能因同一查询所引用的不同对象而异;例如一个表可能很小,因此应用表锁,而另一个大表则可以应用行锁。应用表锁的级别不必由用户指定,而且不需要管理员配置。SQL Server 实例确保在一个粒度级上授予的锁不妨碍在另一个级别上授予的锁。例如,如果 UserA 试图在行上获取共享锁,SQL Server 实例也会试图在页和表上获取意向共享锁。如果 UserB 在页或表级上有一个排它锁,UserA 将被阻塞,直到 UserB 控制的锁被释放才能获取锁。有几种锁模式:共享锁、更新锁、排它锁、意向锁和架构锁。锁模式表明连接与锁定对象所具有的相关性等级。SQL Server 控制锁模式的交互方式。例如,如果其它连接对资源具有共享锁,则不能获得排它锁。锁保持的时间长度为保护所请求级别上的资源所需的时间长度。 用于保护读取操作的共享锁的保持时间取决于事务隔离级别。采用 READ COMMITTED 的默认事务隔离级别时,只在读取页的期间内控制共享锁。在扫描中,直到在扫描内的下一页上获取锁时才释放锁。如果指定 HOLDLOCK 提示或者将事务隔离级别设置为 REPEATABLE READ 或 SERIALIZABLE,则直到事务结束才释放锁。
    根据为游标设置的并发选项,游标可以获取共享模式的滚动锁以保护提取。当需要滚动锁时,直到下一次提取或关闭游标(以先发生者为准)时才释放滚动锁。但是,如果指定 HOLDLOCK,则直到事务结束才释放滚动锁。
    用于保护更新的排它锁将直到事务结束才释放。 
    如果一个连接试图获取一个锁,而该锁与另一个连接所控制的锁冲突,则试图获取锁的连接将一直阻塞到: 将冲突锁释放而且连接获取了所请求的锁。
    连接的超时间隔已到期。默认情况下没有超时间隔,但是一些应用程序设置超时间隔以防止无限期等待。 
    如果几个连接因在某个单独的资源上等待冲突的锁而被阻塞,那么在前面的连接释放锁时将按先来先服务的方式授予锁。SQL Server 有一个算法可以检测死锁,即两个连接互相阻塞的情况。如果 SQL Server 实例检测到死锁,将终止一个事务,以使另一个事务继续。有关更多信息,请参见死锁。 SQL Server 可以动态升级或降级锁粒度或锁类型。例如,如果更新获取大量行锁而阻塞了表的大部分,将行锁升级到表锁。如果获取了表锁,将释放行锁。SQL Server 2000 很少需要升级锁;查询优化器在编译执行计划时通常选择正确的锁粒度。有关更多信息,请参见锁升级和动态锁定。