數(shù)據(jù)庫原理補(bǔ)充：數(shù)據(jù)庫并發(fā)控制軟件設(shè)計(jì)案例

《數(shù)據(jù)庫原理補(bǔ)充：數(shù)據(jù)庫并發(fā)控制軟件設(shè)計(jì)案例》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在教育資源-天天文庫。

1、并發(fā)控制案例分析主講：呂震宇說明實(shí)驗(yàn)環(huán)境：VisualStudio.NET2005SQLServer2005其它說明：SQLServer2000+VS.NET2003也可以需要對代碼做細(xì)微調(diào)整源代碼及數(shù)據(jù)庫見附件并發(fā)控制案例設(shè)某銀行存款帳戶數(shù)據(jù)如下表：現(xiàn)在要求編寫一程序，完成兩項(xiàng)功能：存款與取款。每次操作完成后向明細(xì)表中插入一行記錄并更新帳戶余額。帳號(hào)0001戶名張三序號(hào)金額帳戶余額1￥1,000.00￥1,000.002￥-500.00￥500.003￥200.00￥700.004￥400.00￥1,100.005￥-700.00￥400.001、問題似乎很簡單解決辦法：

2、①讀取最后一行記錄的帳戶余額數(shù)據(jù)②根據(jù)存、取款金額計(jì)算出新的帳戶余額③將新的記錄插入表中真的這么簡單？在不考慮并發(fā)問題的情況下是可行的如果考慮并發(fā)，問題就多了序號(hào)金額帳戶余額………………5-700.00400.00到銀行取錢單位發(fā)工資①銀行讀取帳戶余額400元②單位讀取帳戶余額400元③單位發(fā)工資2000元更新帳戶余額62000.002400.00④取款100元更新帳戶余額7-100.00300.00余額錯(cuò)誤上述解決辦法的并發(fā)問題2、讓我來想一想問題所在：并發(fā)問題！解決辦法：加鎖！在讀最后一條記錄時(shí)先加上鎖。怎么加鎖？加什么鎖？讀之前加共享鎖？讀之前加排它鎖？讀之前

3、加共享鎖？顯然不行！序號(hào)金額帳戶余額………………5-700.00400.00到銀行取錢單位發(fā)工資①銀行讀取帳戶余額400元②單位讀取帳戶余額400元③單位發(fā)工資2000元更新帳戶余額62000.002400.00④取款100元更新帳戶余額7-100.00300.00余額錯(cuò)誤ss讀之前加排它鎖，事務(wù)完成再釋放？三級封鎖協(xié)議中沒有定義讀前加排它鎖（暫且不管）顯然不行！序號(hào)金額帳戶余額………………5-700.00400.00到銀行取錢單位發(fā)工資①銀行讀取帳戶余額400元④單位讀取帳戶余額400元⑤單位發(fā)工資2000元更新帳戶余額72000.002400.00③取款1

4、00元更新帳戶余額6-100.00300.00余額錯(cuò)誤xx②等待…等待…等待…x還不止這些如何讀取帳戶余額？SELECTTOP1帳戶余額FROM帳戶明細(xì)ORDERBY序號(hào)DESC存在的問題：在并發(fā)場景下你怎么確定它一定是最后一行？隨著數(shù)據(jù)量增大越來越?jīng)]效率（因?yàn)樾枰判颍?、看來問題真的不是這么簡單問題出在哪里呢？從系統(tǒng)設(shè)計(jì)一開始我們就走錯(cuò)了！重新設(shè)計(jì)！帳號(hào)戶名帳戶余額帳號(hào)序號(hào)金額帳戶余額0001張三￥400.0000011￥1,000.00￥1,000.0000012￥-500.00￥500.0000013￥200.00￥700.0000014￥400.00￥1,100

5、.0000015￥-700.00￥400.00AccountAccountDetail冗余數(shù)據(jù)為什么引入冗余數(shù)據(jù)？確保帳戶余額在唯一的地方進(jìn)行存儲(chǔ)避免了讀取帳戶余額時(shí)訪問大量數(shù)據(jù)并排序新問題：我們無法直接對數(shù)據(jù)庫進(jìn)行鎖操作必須通過合理的事務(wù)隔離級別完成并發(fā)控制ReadUnCommittedReadCommittedRepeatableReadSerializable4、著急吃不著熱豆腐看來我們必須對各事務(wù)隔離級別逐一分析①ReadUnCommitted顯然不行在這個(gè)事務(wù)隔離級別下連臟數(shù)據(jù)都可能讀到，何況“臟”帳戶余額數(shù)據(jù)。②ReadCommitted也不行該隔離級別與二級封

6、鎖協(xié)議相對應(yīng)。讀數(shù)據(jù)前加共享鎖，讀完就釋放。前面分析過，此處不再贅述。③RepeatableRead這個(gè)隔離級別比較迷惑人，需要仔細(xì)分析：RepeatableRead對應(yīng)第三級封鎖協(xié)議：讀前加共享鎖，事務(wù)完成才釋放。例：假設(shè)事務(wù)1執(zhí)行存錢操作，首先對帳戶余額加S鎖，然后修改數(shù)據(jù)。此時(shí)事務(wù)2要想改帳戶余額，它必須先加X鎖（自然加不上），所以無法完成操作。這似乎避免了并發(fā)問題的發(fā)生，在一個(gè)事務(wù)執(zhí)行時(shí)將另一個(gè)事務(wù)的修改請求暫時(shí)阻塞，直到事務(wù)完成。但真的能滿足應(yīng)用程序的需要嗎？序號(hào)金額帳戶余額………………5-700.00400.00到銀行取錢單位發(fā)工資①銀行讀取帳戶余額400元②

7、單位讀取帳戶余額400元④單位發(fā)工資2000元更新帳戶余額XLock等待…等待…等待…等待…等待…等待…③取款100元更新帳戶余額XLock等待…等待…等待…等待…等待…等待…等待…等待…等待…尚未提交的臟數(shù)據(jù)x帳號(hào)戶名帳戶余額0001張三￥400.00ss6-100.00300.00x72000.002400.00可見RepeatableRead事務(wù)隔離級別容易造成死鎖。一旦出現(xiàn)死鎖，DMBS不得不犧牲一個(gè)進(jìn)程。犧牲進(jìn)程換來的是不會(huì)出現(xiàn)并發(fā)異常。④Serializable該事務(wù)隔離級別在執(zhí)行時(shí)可以避免幻影讀