timestamp应用(解决并发问题)——乐观锁和悲观锁
一个表只能有一个 timestamp 列。每次插入或更新包含 timestamp 列的行时，timestamp 列中的值均会更新。这一属性使 timestamp 列不适合作为键使用，尤其是不能作为主键使用。对行的任何更新都会更改 timestamp 值，从而更改键值。如果该列属于主键，那么旧的键值将无效，进而引用该旧值的外键也将不再有效。如果该表在动态游标中引用，则所有更新均会更改游标中行的 位置。如果该列属于索引键，则对数据行的所有更新还将导致索引更新。
不可为空的 timestamp 列在语义上等价于 binary(8) 列。可为空的 timestamp 列在语义上等价于 varbinary(8) 列。
在实际的多用户并发访问的生产环境里边，我们经常要尽可能的保持数据的一致性。而其中最典型的例子就是我们从表里边读取数据，检查验证后对数据进行修改，然后写回到数据库中。在读取和写入的过程中，如果在多用户并发的环境里边，其他用户已经把你要修改的数据
进行了修改是非常有可能发生的情况，这样就造成了数据的不一致性。解决这样的办法，SQL SERVER提出了乐观锁定和悲观锁定的概念，下边我以一个实例来说明如何使用乐观锁定和悲观锁定来解决这样的问题。
/* 建立测试表:Train_ticket,代表一个真实的火车票库,供用户注册.用户要从里边购买一个未使用的火车票，也就是S_Flag=0的票，给用户 注册：更新T_Name,T_Time,S_Flag字段. 如果出现两个用户同时更新一张票的情况，是不能容忍的，也就是我们所说的数据不一致行。*/
create table Train_ticket(T_NO varchar(20),T_Name varchar(20),S_Flag bit,T_Time datetime)
悲观锁定解决方案
Begin Tran
select top 1 @TrainNo=T_NO
from Train_ticket with (UPDLOCK) where S_Flag=0
update Train_ticket
set T_Name=user,
T_Time=getdate(),
S_Flag=1
where T_NO=@TrainNo
commit
注 意其中的区别了吗?with(updlock),是的,我们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候我们就对记录加上了更新锁,表示我们即将对次记录进行更新.注意更新锁和共享锁是不冲突的,也就是其他用户还可 以查询此表的内容,但是和更新锁和排它锁是冲突的.所以其他的更新用户就会阻塞.如果我们在另外一个窗口执行此代码,同样不加waifor delay子句.两边执行完毕后,我们发现成功的注册了两张火车票.可能我们已经发现了悲观锁定的缺点:当一个用户进行更新的事务的时候,其他更新用户必 须排队等待,即使那个用户更新的不是同一条记录.
乐观锁定解决方案
-- 首先我们在Train_ticket表里边加上一列T_TimeStamp 列,该列是varbinary(8)类型.但是在更新的时候这个值会自动增长.
alter table Train_ticket add T_TimeStamp timestamp not null
-- 取得号和原始的时间戳值
select top 1 @TrainNo=T_No,
@timestamp=T_TimeStamp
from Train_ticket
where S_Flag=0
-- 延迟50秒，模拟并发访问.
waitfor delay '000:00:50'
-- 购买票,但是要比较时间戳是否发生了变化.如果没有发生变化.更新成功.如果发生变化,更新失败.
update Train_ticket
set T_Name=user,
T_Time=getdate(),
S_Flag=1
where T_No = @TrainNo and F_TimeStamp = @timestamp
set @rowcount=@@rowcount
if @rowcount=1
begin
print 'Successful!'
commit
end
else if @rowcount=0
begin
if exists(select 1 from Train_ticket where T_No = @TrainNo)
begin
print 'The ticket was already buyed.'
rollback tran
end
else
begin
print 'This ticket doesn't exist!'
rollback tran
end
end
上边我详细介绍了乐观锁定和悲观锁定的使用方法,在实际生产环境里边,如果并发量不大,我们完全可以使用悲观锁定的方法,因为这种方法使用起来非常方便和简单.但是如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.
