首页 >> 读书频道 >> 电脑 >> RDO 的建立记录集(二)
 
· RDO 的建立记录集(一
· RDO之Informix
· XBase与VB用法对照
· 数据库的锁定
· 如同XBase的Macr
· 如何将其他资料汇入MDB
· Tandem Unstr
· VB数据库记录查询四法
· Visual Basic
· ADO Update C
· ADO的建立连结
· 在记忆体中的ADO记录集
 
· 电视剧《刁蛮公主》下载和
· 美容养颜手册
· 加油金顺剧情分集介绍完整
· 红楼梦:120回全本[清
· 素质教育在美国
· 全唐诗卷四十六
· 韩剧《布拉格恋人》剧情介
· 夜航船[作者:明·张岱]
· 局外人[作者:韩·可爱淘
· 现场流行病学
· 源氏物语[日本:紫式部]
· 武林寓言故事
 
· (出租)中动商场部分及写
· (出租)中动动漫基地&#
· 喜剧学院
· 《善德女王》剧情介绍
· 魔女18号 剧情
· 丑女无敌剧情介绍
· 魔女幼熙剧情介绍
· 龙游天下剧情介绍
· 震撼世界的七日剧情介绍
· 静静的白桦林剧情介绍
· 心情日记—老公今天我想对
· 旗舰剧情介绍
欢迎来到月影社区!如果您觉得这里不错,请推荐给您的朋友们。月影社区:http://wf66.com/

RDO 的建立记录集(二)


查看有无更新版本

关键字:VB 2006-9-18

 

上回提到了OpenResultset方法,可以有以下数种型态的Cursor
rdOpenForwardOnly  rdOpenStatic rdOpenDynamic rdOpenKeyset
也提及了SQL Server/ Informix的Server/Client端Cursor与之搭配的记录,再来讨论
OpenResultset的 LockType,这LockType的设定主要是为了多人同时使用的环境而设。

rdConcurReadOnly 1      (预设值)唯读的。
rdConcurLock     2      悲观的平行。
rdConcurRowVer   3      基於资料列 ID之乐观的平行。
rdConcurValues   4      基於资料列值之乐观的平行。
rdConcurBatch    5      使用批次模式更新之乐观的平行处理。为每一笔成功地被
                        更新的资料列传回 Status 值。

而我们这里针对的是前4者加以讨论。
如果是rdUseODBC 的Client端Cursor,上回提过,它只能有rdOpenForwardOnly 及
rdOpenStatic两种型态(使用其他型态时,可能也不会有误,但行为只有这两种模式)
而使用的锁定模式呢,只能是rdConcurReadOnly/rdConcurValues 而其他的锁定模式呢
使用下去,可能会有错,也可能没有,那要看ODBC Driver的厂商如何写,但其锁定行模
式应只有上述说的这两种(rdConcurBatch我未研究)。

如果是Server端的Cursor(rdUseServer),那才能使用这前四种锁定方式;rdConcurReadOnly
不用多说,那代表该Cursor不是Update Cursor,只能读取。而rdConCurLock是悲观的锁
定,根据我的Testing ,SQL Server6.5 其悲观的锁定的特性是:只要在OpenResultset
时,者就会在RowSetSize数目的列上做一个Update Lock,如果是Page Lock的状态,那
至少会把各个Row所在的Page上的列全Lock住,因此Lock住的列可不只RowSetSize的数目
。当然,这只是某些情况之下会如此,SQL SERVER会看实际的情况来Handle Lock,说不
定会Lock整个Table也不一定。这里要提一下Lock的种类:

Share Lock : 同时之间有很多Procee可以Share Lock住某一笔资料,一般读取时有时会
             在上面做个Share Lock(并不是每一种都会,要看我们先前的设定)
Exclusive Lock : 某一笔Record不能有其他的任何Lock(含Share Lock)时,才能Lock成,
             一般在update/delete等动作时,会先Exclusive Lock该笔,成功时才能再
             做往後的动作。
Update Lock:或称Promotable Lock,这个Lock是为了Current Record有所更动而设计,
            它允许Share Lock与之共存,但不可以有其他的Exclusive/Update Lock存
            在。它在真的要Update时会把Update Lock提升成Exclusive Lock,所以啦,
            在它真的要Update前於其上的所有Lock(包括Share Lock)都要解除才能成功。
+----------------+----------------------------------------------------
|                |           目前已有的Lock                          |
|----------------+---------+-----------+------------+----------------|
|想要完成之Lock  | no lock | Share Lock| Update Lock| Exclusive Lock |
|----------------|---------+-----------+------------+----------------|
|share lock      |   可         可          可            不可       | 
|update lock     |   可         可         不可           不可       |
|exclusive lock  |   可        不可        不可           不可       |
|----------------+---------------------------------------------------+

以下我暂且用Row Lock来解释一些东西,读者可另外推及Page Lock。

一、SQL Server6.5的 rdConCurLock(悲观的锁定)

    这个rdConCurLock会在它读过的Row上做一个Update Lock,那代表什麽?代表其他
的Process如果想读取rdConcurLock方式读过的资料,那没有问题,因为读取的动作顶多
是Share Lock甚而是没有Lock,方才提过,同一Record允许多个Share Lock於其上,所
以只是读取资料时没有问题。如果说Process A 以rdConcurLock方式的Cursor目前指向
ResultSet的第5笔资料,另外有一个Process B 使用乐观锁定的Cursor,且ResultSet成
员相同,而它正指向第1笔资料,Process B 想要来更新资料时会如何?答案是可能无法
更新,因为rdConcurLock已读过第1笔资料,所以在上面做了一个Update Lock,Process B
想Update它,前题是要先能Exclusive Lock该笔,但因其上已有Update Lock所以Lock不成
,而Lock 不成的情况下会如何,那要看我们设定Lock时TimeOut的时间是多少,一次Lock
不成会自动再试着Lock,如果在TimeOut的时间内Lock成功便OK(那更新便可成功),否则就
会产生一个Error。而rdConCurLock的Update Lock何时才会Releas呢?可能是Close ResultSet
或Transaction结束等等。正因rdConCurLock会在其上放Update Lock,所以它不允许其他的
Process也在相同的Resultset上以rdConCurLock的方式开启。相反的,方才的例子中,如果
Process A回头想Update 第一笔资料时则会成功,因为乐观的锁定在读取到资料後,便会
Release Share Lock而变成没有Lock,这在乐观锁定中再详谈。

二、OpenLink的Informix ODBC Driver没有提供rdConcurLock的功能
    就算我们以rdConcurLock的方式来OpenResultset,也不会有错,只是其行为是乐观
的锁定,除非,设定Isolation Level才会有Lock在上面,这容後再述。   

三、SQL的乐观锁定
   乐观锁定分成两种:rdConcurValues/ rdConcurRowVer,这二者的区别主要在於:确定
想修改的那个Row,在读取与想修改之间有没有被其他Process修改过的认知。如果是
rdConcurValues那代表使用的是各个栏位的值,而rdConcurRowVer则是利用Timestamp,
TimeStamp是SQL Server自动维护的一个栏位,当某个Row有更新时,便会自动更新於其上
的TimeStamp栏位,所以我们Update时,SQL Server会用原始读出的TimeStamp值与目前的
TimeStamp值做一比较,如果不同代表先前已被别人Update了,因此rdConcurRowver比较有
效率。而Table中就要有timestamp的栏位才能使用rdConcurRowver,否则在OpenResult时
会产生一个Warnning。除此之外,这两种乐观锁定似乎没有太大不同。

    乐观锁定很奇特,它在读取出资料时(如OpenResultSet)会产生Share Lock,而读取出
资料之後的所有Record含Current Record竟然没有做锁定(连Share Lock也没有),而且不管
我们的Cursor是否是Update Cursor都如此,只有在Update时才会去做Exclusive Lock。如
果,这个Update指令是under Transaction那这Exclusive Lock不会去除,等Transaction
Committed/RollBack 时才Release。再来一个Case,如果Process A以乐观锁定的方式来
开启Resultset,Process B也以乐观的锁定开启相同的Resultset,而且二者同时皆指向同
一笔Record,Process A先行Update该笔,而後Process B再想Update时,会产生错误,如果
是以rdOpenKetset/rdOpenDynamic方式那Process B便得先rs.Move 0, rs.Edit重新修正
资料最後再rs.Update一次。请和先前一个Process是悲观锁定,一个是乐观锁定而Update
不同笔资料做一比较,为何之前的Update指令会等待Process A的Resultset 去除锁定,
而这个例子是什麽也不等,一下子就产生Error?(提示:这个例子中,Process A update
之後便Release Lock变成没有Lock),当然这个例子是没有Under Transaction时的记录,
反过来,如果Under Transaction呢,Process A先Update该Reocrd後未Commit/Rollback
前,在该笔(或其所在的Page)会有一个Exclusive Lock,此时如果Process B来Update时
则会进入等待,直到Procees A如果Commit Transaction则Process B的Update产生Error
或者Process A Rollback Transaction则Process B的Update可成功。

    这和我原本的想像不同,我原本的想法,Server端的Cursor是由Declare Cursor/
Open Cursor/Fetch/Close Cursor等指令直接来做,但是我查一些书,得知如果是Update
Cursor在Fetch到资料时,会在Current Record所在的Page上做Update Lock,如果不是Update
Cursor则做Share Lock,而且其Lock会一直保存,直到下一个Fetch或Close Cursor或
Commit/Rollback Transaction等,而不是像现在只有读出的那一个时点会做Lock,读出後
便不Lock了。这中间的行为模式之不同,应是ODBC与Server端的Cursor间另有一个机制所造成
,而我不知这中间的机制是什麽。
            
四、InforMix的乐观锁定
    基本上,Informix的乐观锁定和SQL Server没有太大的不同,然而Informix提供Row
Lock的功能,这是和SQL Server不同之处。

上面说明了ODBC乐观锁定和悲观锁定的行为模式,基本上,说明的是读取到资料之後,与
Updtae资料之後,使用何种Lock於Current Record或读取过的Record,而我上面的说明全
来自我的Testing,我分别使用SQL EnterPrise Manager与Informix Sysmaster Database
的syslocks Table来查寻Lock的情况。但这里还有一个重点没有说到,那就是什麽情况之
下才能顺利"读取到"资料;而上面的讨论是读取成功之後,有没有要在Object上做Lock。
这是Set Transaction Isolation Level的讨论范围。请查下一个Topic

RDO 的建立记录集(二)

[ 1 ]
RDO 的建立记录集(二) num

打印本页 关闭

关于我们版权声明本站导航友情连结作品演示 TOP↑