Kendy123456 进来

前面提到大部分锁定信息是SQL自动判定的,那么我们用代码可以控制什么呢?
1.我们可以设置事务隔离等级
事务准备接受不一致数据的级别称为隔离级别。隔离级别是一个事务必须与其它事务进行隔离的程度。较低的隔离级别可以增加并发，但代价是降低数据的正确性。相反，较高的隔离级别可以确保数据的正确性，但可能对并发产生负面影响。
语法
SET TRANSACTION ISOLATION LEVEL
{ READ COMMITTED
| READ UNCOMMITTED
| REPEATABLE READ
| SERIALIZABLE
}

参数
READ COMMITTED

指定在读取数据时控制共享锁以避免脏读，但数据可在事务结束前更改，从而产生不可重复读取或幻像数据。该选项是 SQL Server 的默认值。

READ UNCOMMITTED

执行脏读或 0 级隔离锁定，这表示不发出共享锁，也不接受排它锁。当设置该选项时，可以对数据执行未提交读或脏读；在事务结束前可以更改数据内的数值，行也可以出现在数据集中或从数据集消失。该选项的作用与在事务内所有语句中的所有表上设置 NOLOCK 相同。这是四个隔离级别中限制最小的级别。

REPEATABLE READ

锁定查询中使用的所有数据以防止其他用户更新数据，但是其他用户可以将新的幻像行插入数据集，且幻像行包括在当前事务的后续读取中。因为并发低于默认隔离级别，所以应只在必要时才使用该选项。

SERIALIZABLE

在数据集上放置一个范围锁，以防止其他用户在事务完成之前更新数据集或将行插入数据集内。这是四个隔离级别中限制最大的级别。因为并发级别较低，所以应只在必要时才使用该选项。该选项的作用与在事务内所有 SELECT 语句中的所有表上设置 HOLDLOCK 相同。

可以通过指定表级锁定提示来替代单个 SELECT 语句的隔离级别。指定表级锁定提示不会影响会话中的其它语句。

2.可以设置表级锁定

对表操作的SQL语句可以单独设置锁定信息

HOLDLOCK 将共享锁保留到事务完成，而不是在相应的表、行或数据页不再需要时就立即释放锁。HOLDLOCK 等同于 SERIALIZABLE。
NOLOCK 不要发出共享锁，并且不要提供排它锁。当此选项生效时，可能会读取未提交的事务或一组在读取中间回滚的页面。有可能发生脏读。仅应用于 SELECT 语句。
PAGLOCK 在通常使用单个表锁的地方采用页锁。
READCOMMITTED 用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上操作。
READPAST 跳过锁定行。此选项导致事务跳过由其它事务锁定的行（这些行平常会显示在结果集内），而不是阻塞该事务，使其等待其它事务释放在这些行上的锁。READPAST 锁提示仅适用于运行在提交读隔离级别的事务，并且只在行级锁之后读取。仅适用于 SELECT 语句。
READUNCOMMITTED 等同于 NOLOCK。
REPEATABLEREAD 用与运行在可重复读隔离级别的事务相同的锁语义执行扫描。
ROWLOCK 使用行级锁，而不使用粒度更粗的页级锁和表级锁。
SERIALIZABLE 用与运行在可串行读隔离级别的事务相同的锁语义执行扫描。等同于 HOLDLOCK。
TABLOCK 使用表锁代替粒度更细的行级锁或页级锁。在语句结束前，SQL Server 一直持有该锁。但是，如果同时指定 HOLDLOCK，那么在事务结束之前，锁将被一直持有。
TABLOCKX 使用表的排它锁。该锁可以防止其它事务读取或更新表，并在语句或事务结束前一直持有。
UPDLOCK 读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。UPDLOCK 的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。
XLOCK 使用排它锁并一直保持到由语句处理的所有数据上的事务结束时。可以使用 PAGLOCK 或 TABLOCK 指定该锁，这种情况下排它锁适用于适当级别的粒度


我认为对前面那个贴的问题, Insert的时候设置HoldLock应该可以锁定该行直到整个事务结束, 以确保insert之后的select不会发生被人更改了标识列的情况.

吃饭了 一会继续讨论

[QUOTE]
<%
'游标类型
Const adOpenForwardOnly = 0
Const adOpenKeyset = 1
Const adOpenDynamic = 2
Const adOpenStatic = 3

'加锁类型
Const adLockReadOnly = 1
Const adLockPessimistic = 2
Const adLockOptimistic = 3
Const adLockBatchOptimistic = 4
>%

<% Set Conn = Server.CreateObject('ADODB.Connection') >%
<% Set RSMov = Server.CreateObject('ADODB.RecordSet') >%
<% Conn.Open '数据源名称', 'sa', '' >%
<% RSMov.Open sqlMov, Conn, adOpenKeyset, adLockReadOnly >%
游标使用时是比较灵活的，它有时用来描述一个记录集，有时又是用来描述当前记录集
中某一条记录的指针。游标主要是用来建立一个关系数据库中行/列关系的一种SQL可利
用的访问格式。与游标有关系的技术术语还有一个叫Bookmark的。如果你选择的游标方式
支持Bookmarks。数据库将提供有关记录数目的强大功能。
在上面写出的那么多游标方式中，adOpenDynamic是没有太的用处的，虽然它提供实时显示
数据库中的记录的所有更新操作的功能，但是因为并不是所有的数据库都支持该游标方式，
没有移植性的游标方式对当前错综复杂的数据库来说真是用处不大。
在实际的编程中，我相信大家使用得最频繁的是adOpenStatic方式，当然这种方式的缺点是
不能够就、实时反应出数据库中内容改变时的状况。如果要想看到数据库被其它用户改变的
状况，可使用adOpenKeyse方式（但是它只能够反应出被编辑的改变情况，也就是说不能够
反映出新增和删除记录的改变情况。）
其实上面的内容大家一般都可以在微软的技术参考资料中找到，下面来说说在使用这些游标
方式和加锁方式时要注意到的问题。
1。首先要注意到的是这两种方式在混合使用时的问题，就是说你同时设置游标方式和加锁方式。
除非你是在使用Access数据库，一般而言当你混合使用时是并不能够得到你预期想要的
游标方式和加锁方式的。例如，如果你同时将游标设置为adOpenStatic方式，而将加锁设置为
adLockOptimistic，你将得不到adOpenStatic方式的游标，你这时使用的游标方式将是
adOpenKeyset，也就是说你使用ADO的话，它将返回adOpenKeyset的游标。
2。其次，游标和加锁的混合使用还会导致ADO返回的不是你想要的加锁方式，ADO会改变你的加锁
方式。例如，在默认状态下游标方式是adOpenForwardOnly，在使用这种游标方式的同时如果
你使用的加锁方式为-1（就是让数据源来判断加锁方式）或则adLockReadOnly，那么这种混合方式
基本上不支持RecordSet的任何方法，也就是说RecordSet的任何方法将返回False
(你的recordcount,absoultpage,addnew,delete,update等都会返回-1，-1就是表示不支持该属性)，
但是这时如果你使用的是adOpenForwardOnly游标方式和其它的加锁方式混合，它反而
会支持填加，删除和更新。

[/QUOTE]---CSDN

事务在未提交前 加的意向锁和SQL语句本身产生的锁是不冲突的. 意向锁是表级的, 表示整个事务目前对表的锁定意向; SQL语句指定的表锁定实际上应该是行锁定, 仅仅在锁定过多 达到升级门限的时候才会自动被SQL server升级为页锁定或者表锁定. 而且 判定事务阻塞的时候 意向锁并不是判定的依据.(它只能判定事务不阻塞)
一个insert语句下来, 这个表就会有一个意向排它锁, 并且不被释放. 同时会产生一个排它锁, 并在insert完成之后释放. (否则就不存在幻读了) 而HOLDLock是声明在insert完成之后也维持这个行级的排他锁(仅锁定insert产生的行)不释放,要整个事务提交的时候才释放. 这是我的理解, 我觉得声明为holdlock实际上就等于把这一行的事务隔离级别单独设置成了可串行读, 在这个事务结束前, 对于其它事务而言这行数据将是不可访问的.

事实上锁定的问题除了专业人士, 很少有人专门去研究, 因为太难调试和测试. 我的理解也不一定就对.

[此贴子已经被作者于2007-1-29 15:11:17编辑过]

并发控制的专业流程我也不清楚, 我可以谈一下我目前开发的系统中使用的并发控制模式.
在用户通过访问了数据库记录后, 如果后续的操作牵涉到写操作(insert ,update 和 delete), 我们在一张专门的系统设置表中给它的主键打上锁定标识; 如果存在外键则访问到主表给主表记录打上锁定; 在操作完成之后则解除锁定; 期间其它的会话如果企图访问该行将会程序判定拒绝. 产生的问题在于如果操作非正常结束,那么锁定标识会一致存在, 所以管理员界面中我们有一个锁定列表让管理员可以手工解除锁定. 当然, 如果正常锁定期间, 管理员手工解除锁定, 仍然有可能引发冲突和异常.所以错误判定和异常处理仍然是不可缺少的(定义一大堆的RaiseError和对应操作确实是很让人头疼的事情)

行级锁是保持的,但是insert不受影响
begin tran
insert into student select 2,'aa'
这句执行完后

spid dbid ObjId IndId Type Resource Mode Status
------ ------ ----------- ------ ---- ---------------- -------- ------
51 7 0 0 DB S GRANT
51 7 2105058535 0 RID 1:15:0 X GRANT
51 7 0 0 PAG 1:15 IX GRANT
51 1 85575343 0 TAB IS GRANT
51 7 2105058535 0 TAB IX GRANT
行级锁行保留着

begin tran
insert into student with(holdlock) select 6,'kk'

这句执行完后结果和上面一样
spid dbid ObjId IndId Type Resource Mode Status
------ ------ ----------- ------ ---- ---------------- -------- ------
51 7 0 0 DB S GRANT
51 7 2105058535 0 RID 1:15:0 X GRANT
51 7 0 0 PAG 1:15 IX GRANT
51 1 85575343 0 TAB IS GRANT
51 7 2105058535 0 TAB IX GRANT

begin tran
select * from student
这句执行完之后
spid dbid ObjId IndId Type Resource Mode Status
------ ------ ----------- ------ ---- ---------------- -------- ------
51 7 0 0 DB S GRANT
51 1 85575343 0 TAB IS GRANT
行级锁解除了

begin tran
select * from student with(holdlock)
这句执行完之后
spid dbid ObjId IndId Type Resource Mode Status
------ ------ ----------- ------ ---- ---------------- -------- ------
51 7 0 0 DB S GRANT
51 1 85575343 0 TAB IS GRANT
51 7 2105058535 0 TAB S GRANT
共享锁还保留着

那你试试用另外个事务去select * from students 看能不能访问到? 如果不能的话 那就确实是什么也不用做 自然好...

也不能做了,是不是行被锁住了,没法查询了

我是说select的时候才会出现幻读,没说insert会出现幻读啊

我打断一下
jinyuzhang
bygg
kendy123456

说实在的，我觉得你们的知识面非常宽，小弟真的很佩服
你们现在都出来工作了吗？
这些问题应该在真正的系统开发的时候才能遇到吧，比如说事务，并发的知识（老师给我们讲得太简单了，没有你们说得那么详细）

我也是最近才看了一些相关的知识,呵,学习中哦,希望大家多帮帮我才是啊.

就是不知道怎么用！！怎么在实践中灵活的运用起来