|
由于在BugTiger中需要用到?jīng)_突檢測(cè),所以對(duì)沖突檢測(cè)進(jìn)行了學(xué)習(xí),現(xiàn)總結(jié)了如下四種方法:
在數(shù)據(jù)庫(kù)的表中添加一個(gè)時(shí)間戳列或版本列.時(shí)間戳列與對(duì)表內(nèi)容的查詢一起返回.當(dāng)試圖更新時(shí),數(shù)據(jù)庫(kù)中的時(shí)間戳值將與被修改行中的原始時(shí)間戳值進(jìn)行比較.如果這兩個(gè)值匹配,則執(zhí)行更新,同時(shí)時(shí)間戳列被更新為當(dāng)前時(shí)間以反映更新.如果這兩個(gè)值不匹配,則發(fā)生開(kāi)放式并發(fā)沖突. 表結(jié)構(gòu)(Method1):
當(dāng)用戶取得數(shù)據(jù)時(shí),將BugTimeStamp列也返回給用戶.  SELECT BugID, BugType, BugTimeStamp  FROM Method1 當(dāng)用戶更新時(shí) BugTimeStamp作為條件進(jìn)行比較. UPDATE Method1 SET BugType = ‘b‘ WHERE (BugID = 1) AND (BugTimeStamp = 0x00000000000004B1)更新時(shí)如果從上次讀取數(shù)據(jù)到這次更新這段時(shí)間內(nèi)已經(jīng)被更改過(guò)了 ,條件顯然是不成立了.因?yàn)槊看胃掠涗洉r(shí),timestamp 列中的值均會(huì)更新.在查詢數(shù)據(jù)庫(kù)的數(shù)據(jù)時(shí)保留原始數(shù)據(jù)值的一個(gè)副本.在更新數(shù)據(jù)庫(kù)時(shí),檢查數(shù)據(jù)庫(kù)的當(dāng)前值是否與原始值匹配.原始值保存在 DataSet 中,當(dāng)更新數(shù)據(jù)庫(kù)時(shí),數(shù)據(jù)適配器可以使用該原始值執(zhí)行開(kāi)放式并發(fā)檢查. 表結(jié)構(gòu)(Method2)
 UPDATE Tasks   SET BugType = @ BugType   WHERE (BugID = @BugD) AND (BugType = @Original_BugType)  SqlUpdateCommand1.Parameters.Add(new SqlParameter("@Original_BugType", SqlDbType.Char, 10, ParameterDirection.Input, false, 0, 0, " BugType ", DataRowVersion.Original, null));
可以通過(guò)一表中的最后更新時(shí)間(LastUpdateDate)和最后更新用戶(LastUpdateUserID)來(lái)確定一條記錄是否已經(jīng)被其他用戶修改.如果只用最后更新時(shí)間,還是會(huì)有沖突發(fā)現(xiàn),雖然這樣的概率比較低,因?yàn)?/SPAN>DateTime的精確度為百分之三秒,在A用戶取出后的足夠短的時(shí)間內(nèi)有B用戶修改了數(shù)據(jù),這時(shí)最后更新時(shí)間沒(méi)有發(fā)生變化,但是數(shù)據(jù)有變化了,所以當(dāng)A用戶修改時(shí)實(shí)際上已經(jīng)發(fā)生了沖突.使用最后更新用戶(LastUpdateUserID)后,還是上述情況,由于LastUpdateUserID已經(jīng)更改,只要A用戶更新時(shí)同時(shí)檢查最后更新時(shí)間(LastUpdateDate)和最后更新用戶(LastUpdateUserID)就可以檢查出沖突. 在這種方法里假設(shè)了同一用戶在百分之三秒不可能進(jìn)行兩次更新.我覺(jué)得這樣的假設(shè)在通常情況下是合理的. 示例: 表結(jié)構(gòu)(Method3)
 SELECT [BugID], [BugProject], [BugType], [LastUpdateDate], [LastUserID] FROM [Method3] 更新數(shù)據(jù)時(shí)  UPDATE [Method3]  SET BugID = @BugID, [BugProject] = @BugProject, [BugType] = @BugType, [LastUpdateDate] = @LastUpdateDate , [LastUserID]= @LastUserID,  WHERE [BugID]= @BugID , [LastUpdateDate]=@ OriginalLastUpdateDate , [LastUserID] = @OriginalLastUserID
SQL聯(lián)機(jī)叢書(shū)上的解釋: 在表中任一行上計(jì)算的 BINARY_CHECKSUM(*) 返回相同的值,只要隨后沒(méi)有修改行.BINARY_CHECKSUM(*) 將為大多數(shù)（但不是全部）行更改返回不同的值,并可用于檢測(cè)大多數(shù)行修改. BINARY_CHECKSUM 在計(jì)算中忽略具有不可比數(shù)據(jù)類型的列.不可比數(shù)據(jù)類型是 text、ntext、image、cursor 以及基本類型為前 4 個(gè)數(shù)據(jù)類型之一的 sql_variant. 字符串的區(qū)域設(shè)置可能導(dǎo)致具有不同表示法的字符串進(jìn)行等值比較.在區(qū)分大小寫(xiě)的服務(wù)器中,字符串"McCavity"和"Mccavity"的 BINARY_CHECKSUM 值不同.反之,在不區(qū)分大小寫(xiě)的服務(wù)器中,上述字符串的 CHECKSUM 返回相同的校驗(yàn)值. 示例. 表結(jié)構(gòu)(Method4)
 SELECT [BugType], BINARY_CHECKSUM(*) AS RowCheckSum FROM [Method4]
 UPDATE Method4 SET BugType = ‘b‘ WHERE (BugID = 1) AND (CHECKSUM(*) = @ RowCheckSum)  四種方式的比較 1. 優(yōu)點(diǎn):實(shí)現(xiàn)比較簡(jiǎn)單,timestamp 列中的值會(huì)更新.不足:要增加一個(gè)額外的字段. 2. 優(yōu)點(diǎn):可靠,不需要額外字段.不足:當(dāng)字段較多時(shí)需要較多的參數(shù). 3. 優(yōu)點(diǎn):和2相比,傳遞的參數(shù)較少.不足:使用的字段對(duì)系統(tǒng)不一定有存在的意義,如例子中的最后更新時(shí)間(LastUpdateDate)和最后更新用戶(LastUpdateUserID)有時(shí)對(duì)系統(tǒng)不是必需的. 4. 優(yōu)點(diǎn):不需要額外字段,只需要一個(gè)參數(shù).不足:有些數(shù)據(jù)類型不可比BINARY_CHECKSUM, 字符串的區(qū)域設(shè)置可能導(dǎo)致具有不同表示法的字符串進(jìn)行等值比較. 只為大多數(shù)（但不是全部）行更改返回不同的值. (筆者注:不知道這個(gè)大多數(shù)是什么概率.) 參考文檔 n 《數(shù)據(jù)層組件設(shè)計(jì)與數(shù)據(jù)傳遞》http://www.yesky.com/20021112/1639500.shtml n hudan 的留言http://zitiger.cnblogs.com/archive/2005/08/05/208580.aspx#208605 n TaskVision http://www./Applications/application.aspx?PageID=20&tabindex=8 n IssueVision http://www./Applications/application.aspx?PageID=40&tabindex=8 n 《SQL Server 聯(lián)機(jī)叢書(shū)》 n 《MSDN》 |
|
|
