在实际的多用户并发访问的生产环境里边,我们经常要尽可能的保持数据的一致性。而其中最典型的例子就是我们从表里边读取数据,检查验证后对数据进行修改,然后写回到数据库中。
注意其中的区别了吗?with(updlock),是的,我们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候我们就对记录加上了更新锁,表示我们即将对次记录进行更新.注意更新锁和共享锁是不冲突的,也就是其他用户还可以查询此表的内容,但是和更新锁和排它锁是冲突的.所以其他的更新用户就会阻塞.如果我们在另外一个窗口执行此代码,同样不加waifor delay子句.两边执行完毕后,我们发现成功的注册了两张卡.可能我们已经发现了悲观锁定的缺点:当一个用户进行更新的事务的时候,其他更新用户必须排队等待,即使那个用户更新的不是同一条记录. U{uR5Rd
Kl].5aB
乐观锁定解决方案 yr1Z#n}
L 7mn/
-- 首先我们在Card表里边加上一列F_TimeStamp 列,该列是varbinary(8)类型.但是在更新的时候这个值会自动增长. eXJ 59
_b?(n#S
alter table Card add F_TimeStamp timestamp not null .tCVKR+N
t`lkX{=n
/2^d!r_
-- 悲观锁定 Urf2_Ey g
declare @CardNo varchar(20) 9\Lz6au
declare @timestamp varbinary(8) H{)Ck/OMgZ
declare @rowcount int ",.c=
&_J0TuF.
Begin Tran n'=yR
1oA|w0;"
-- 取得卡号和原始的时间戳值 t$O5kFa?
select top 1 @CardNo=F_CardNo, yuagB&'F/
@timestamp=F_TimeStamp =,3|Wtze<
from Card 1nEs4#+\`
where F_Flag=0 $8:qb{,k
#}iQ "(<
-- 延迟50秒,模拟并发访问. -L,c m z
waitfor delay '000:00:50' J&sfEq!g
: Ptb?p
-- 注册卡,但是要比较时间戳是否发生了变化.如果没有发生变化.更新成功.如果发生变化,更新失败. lGd[<14LO
TJN~]"
update Card 7hGe[!&l
set F_Name=user, ]ZCG+i
F_Time=getdate(), c-L t
F_Flag=1 U\ )5
where F_CardNo=@CardNo and F_TimeStamp=@timestamp U#3C%^y
set @rowcount=@@rowcount SCp.U &}K
if @rowcount=1 l}/j3Vy
begin )VK.2g#e&
print '更新成功!' ]7.sGr`
commit fA#v MP@
end v5#3KU
else if @rowcount=0 Ujf$Es9@BL
begin d!srL7O
if exists(select 1 from Card where F_CardNo=@CardNo) vg#i069}
begin k45:B(F
print '此卡已经被另外一个用户注册!' `G W^#:z
rollback tran < g{%(*[
end (A./.6H/
else (4PK PIFV
begin 6F"HoWC
print '并不存在此卡!' Ias! b%*i(
rollback tran 8~-S5[,[
end d#!`j
end u]n0?
60OG}tuE Y
在另外一个窗口里边执行没有waitfor的代码,注册成功后,返回原来的窗口,我们就会发现到时间后它显示的提示是此卡以被另外一个用户注册的提示.很明显,这样我们也可以避免两个用户同时注册一张卡的现象的出现.同时,使用这种方法的另外一个好处是没有使用更新锁,这样增加的系统的并发处理能力. V9tZV\&
:UC)pwEV
上边我详细介绍了乐观锁定和悲观锁定的使用方法,在实际生产环境里边,如果并发量不大,我们完全可以使用悲观锁定的方法,因为这种方法使用起来非常方便和简单.但是如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法. x+[TQM]
v -BgLX
如果大家发现文章里边有什么错误的地方,请及时提醒我,也欢迎有兴趣的一起研究讨论.