周薇

摘要： 丟失更新（lost update）是一個(gè)經(jīng)典的數(shù)據(jù)庫問題，在多用戶計(jì)算機(jī)環(huán)境中存在。作為一名數(shù)據(jù)庫開發(fā)者，通過感同身受的例子，向大家展示何為丟失更新現(xiàn)象，并對這種現(xiàn)象進(jìn)行一定的研究。同時(shí)，提出幾種防止的策略。

關(guān)鍵詞：數(shù)據(jù)庫；丟失更新；防止策略

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2014）24-5593-02

Lost Update Phenomena of Research in the Database Concurrency Operations

ZHOU Wei

（Wuxi Institute of Technology， Wuxi 214121， China）

Abstract： Lost update is a classic database problem. It exists in a multi-user computer environment. As a database developer， through empathy example， to show what is lost update phenomenon， and conduct some research this phenomenon. Meanwhile， put forward several prevention strategies.

Key words： database； lost update； prevention strategies

1 概述

當(dāng)2個(gè)或多個(gè)用戶同時(shí)（時(shí)間上重疊）編輯同一行數(shù)據(jù)時(shí)會發(fā)生丟失更新，特別是在基于Web的應(yīng)用程序中常常出現(xiàn)。在實(shí)際運(yùn)行過程中，可能在幾天甚至幾個(gè)月中才會出現(xiàn)一次。這種現(xiàn)象只是隨機(jī)地、零星地出現(xiàn)，而且在受控環(huán)境中完全不可再生，對應(yīng)用程序是致命的。導(dǎo)致開發(fā)人員誤以為是用戶的錯誤，其實(shí)是開發(fā)人員在編寫應(yīng)用程序的時(shí)候，沒有處理好DML命令。

2 丟失更新的現(xiàn)象

丟失更新是指2個(gè)或多個(gè)事務(wù)讀取同一數(shù)據(jù)并進(jìn)行修改，其中一個(gè)事務(wù)的修改結(jié)果破壞了另一個(gè)事務(wù)修改的結(jié)果。有兩類丟失更新：

1） A事務(wù)撤銷時(shí)，把已經(jīng)提交的B事務(wù)的更新數(shù)據(jù)覆蓋了。這種錯誤可能造成很嚴(yán)重的問題。A事務(wù)在撤銷時(shí)，“不小心”將B事務(wù)已經(jīng)轉(zhuǎn)入賬戶的金額給抹去了。

2） A事務(wù)覆蓋B事務(wù)已經(jīng)提交的數(shù)據(jù)，造成B事務(wù)所做操作丟失。由于轉(zhuǎn)賬事務(wù)覆蓋了取款事務(wù)對存款余額所做的更新，導(dǎo)致銀行最后損失了100元，相反如果轉(zhuǎn)賬事務(wù)先提交，那么用戶賬戶將損失100元。

在此過程中，買家A的“取消”訂單的動作，發(fā)生丟失。同時(shí)，對賣家造成了一定的經(jīng)濟(jì)損失。

如何防止買家A的“取消”動作不會丟失，或者賣家的“發(fā)貨”動作不會丟失呢？下面提出4種策略，加以證明。

4 防止丟失更新的策略

1） 設(shè)置數(shù)據(jù)庫的隔離級別為Serializable

當(dāng)是查詢操作的時(shí)候添加共享鎖，共享鎖下被人可以訪問同一條記錄；當(dāng)進(jìn)行修改操作的時(shí)候加排他鎖，別人不可以修改。內(nèi)在機(jī)制是異常退出機(jī)制。

賣家查詢訂單的時(shí)候，給這個(gè)訂單記錄添加了共享鎖，買家可以查看。同理，買家查看他的訂單的時(shí)候，也為自己的記錄添加了共享鎖，但共享鎖下不能再添加排他鎖。當(dāng)賣家想做修改操作（“發(fā)貨”）的時(shí)候，給這個(gè)訂單記錄添加一個(gè)排他鎖是加不上的，他需要等，等待買家釋放了共享鎖，也就是提交了事務(wù)，這個(gè)排它鎖才可以加上。但此時(shí)，如果買家也想操作這個(gè)訂單記錄，想給他的訂單記錄添加排他鎖，也是不可以的，因?yàn)橘u家那邊已經(jīng)有了共享鎖，買家想操作的話，也必須讓賣家去釋放這個(gè)共享鎖。這樣，賣家就要等買家，買家也要等賣家。假設(shè)，此時(shí)買家做了修改的操作，根據(jù)共享鎖存在的情況下，不能加排他鎖的原則，買家那里就會出現(xiàn)異常。此時(shí)這個(gè)“取消”操作終止，“取消”操作無效。就不會產(chǎn)生“取消”操作的丟失。

2） 悲觀鎖

一種進(jìn)行修改的時(shí)候，就給這條訂單記錄加鎖，別人就不能再操作了。悲觀鎖就是程序員認(rèn)為，客戶訪問某條記錄的時(shí)候，很有可能其他人也在訪問同條記錄。保險(xiǎn)起見，為這條訂單記錄加一把悲觀鎖，此時(shí)其他任何人都不可以修改這條記錄。這種鎖，適用于更新多查詢少的系統(tǒng)。

3） 樂觀鎖

樂觀鎖就是指當(dāng)買家或賣家要修改一條訂單記錄的時(shí)候，不認(rèn)為會有別人和自己同時(shí)操作這條訂單記錄?？衫弥辽賰煞N方式實(shí)現(xiàn)：

（1） 在訂單表中，添加一個(gè)version字段，數(shù)據(jù)類型為identity，表示版本

在修改的的時(shí)候利用版本號機(jī)制，那么別人的操作會因?yàn)榘姹咎柕牟町惗?。?dāng)?shù)谝淮尾僮鞯耐戤叺臅r(shí)候，這個(gè)版本號就自動加1，此時(shí)別人如果想要修改這條記錄的時(shí)候，會因?yàn)榘姹咎柕脑蚓筒荒茏鲂薷牧?。適用于查詢多更新少的系統(tǒng)。

（2） 在訂單表中，添加一個(gè)timestamp字段，數(shù)據(jù)類型也為timestamp時(shí)間戳（類似于郵局的郵戳）

時(shí)間戳列中存放的是一個(gè)十六進(jìn)制的數(shù)據(jù)，不管是買家或賣家的任何操作，都會產(chǎn)生一個(gè)唯一的時(shí)間戳值。在賣家“發(fā)貨”或買家“取消”訂單的時(shí)候，都會檢測時(shí)間戳值的值有沒有發(fā)生變化。如果不變，則繼續(xù)；反之，則操作不能進(jìn)行。

4） 通過IF語句搭配訂單狀態(tài)的檢查，也可防止丟失更新

（1） 假如買家想“取消”訂單，操作代碼如圖3。

（2） 假如賣家想為訂單“發(fā)貨”，操作代碼如圖4。

圖4 發(fā)貨

這樣，不管“取消”、“發(fā)貨”兩個(gè)動作發(fā)生的先后次序如何，均不會發(fā)生“取消”丟失，或“發(fā)貨”丟失。

5 結(jié)束語

在數(shù)據(jù)庫并發(fā)操作過程中，如果丟失更新的現(xiàn)象，數(shù)據(jù)庫開發(fā)人員在設(shè)計(jì)的時(shí)候，就能考慮全面，那么是完全能夠避免的。除

了程序控制外，還有許多工具也可以保護(hù)、避免這種情況，如Oracle Forms和HTML DB等。這些工具能確保：從查詢記錄的那個(gè)時(shí)刻開始，這個(gè)記錄沒有改變，而且對它執(zhí)行任何修改時(shí)都會將其鎖定。為了用戶的切身利益，作為一名數(shù)據(jù)庫開發(fā)者，將繼續(xù)研究丟失更新的現(xiàn)象，尋求更多的解決辦法。

參考文獻(xiàn)：

[1]（美）劉易斯.數(shù)據(jù)庫與事務(wù)處理[M]. 1版.北京：機(jī)械工業(yè)出版社，2005：537-547.

[2] 程云志.數(shù)據(jù)庫原理與SQL Server 2005應(yīng)用教程[M]. 1版.北京：機(jī)械工業(yè)出版社，2012：236-240.

[3] 蔣瀚洋，李月軍，龐婭娟.SQL Server 2005數(shù)據(jù)庫管理與開發(fā)教程[M]. 1版.北京：人民郵電出版社，2009：147-152.

[4] 陸琳，劉桂林.數(shù)據(jù)庫技術(shù)與應(yīng)用-SQL server 2005（應(yīng)用篇）[M]. 1版.長沙：中南大學(xué)出版社，2010：290-295.

[5] 呂鵬.數(shù)據(jù)庫更新丟失解決方案.IT/計(jì)算.[2011-08-10].

[6] 孟憲虎，馬雪英，鄧緒斌.大型數(shù)據(jù)庫管理系統(tǒng)技術(shù)、應(yīng)用與實(shí)例分析——基于SQL Server 2005[M]. 2版.北京：電子工業(yè)出版社，2011：119-137

[7] 李萍，黃可望，黃能耿.SQL Server 數(shù)據(jù)庫應(yīng)用及實(shí)訓(xùn)[M].1版.無錫職業(yè)技術(shù)學(xué)院，2014：96-102.endprint

摘要： 丟失更新（lost update）是一個(gè)經(jīng)典的數(shù)據(jù)庫問題，在多用戶計(jì)算機(jī)環(huán)境中存在。作為一名數(shù)據(jù)庫開發(fā)者，通過感同身受的例子，向大家展示何為丟失更新現(xiàn)象，并對這種現(xiàn)象進(jìn)行一定的研究。同時(shí)，提出幾種防止的策略。

關(guān)鍵詞：數(shù)據(jù)庫；丟失更新；防止策略

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2014）24-5593-02

Lost Update Phenomena of Research in the Database Concurrency Operations

ZHOU Wei

（Wuxi Institute of Technology， Wuxi 214121， China）

Abstract： Lost update is a classic database problem. It exists in a multi-user computer environment. As a database developer， through empathy example， to show what is lost update phenomenon， and conduct some research this phenomenon. Meanwhile， put forward several prevention strategies.

Key words： database； lost update； prevention strategies

1 概述

當(dāng)2個(gè)或多個(gè)用戶同時(shí)（時(shí)間上重疊）編輯同一行數(shù)據(jù)時(shí)會發(fā)生丟失更新，特別是在基于Web的應(yīng)用程序中常常出現(xiàn)。在實(shí)際運(yùn)行過程中，可能在幾天甚至幾個(gè)月中才會出現(xiàn)一次。這種現(xiàn)象只是隨機(jī)地、零星地出現(xiàn)，而且在受控環(huán)境中完全不可再生，對應(yīng)用程序是致命的。導(dǎo)致開發(fā)人員誤以為是用戶的錯誤，其實(shí)是開發(fā)人員在編寫應(yīng)用程序的時(shí)候，沒有處理好DML命令。

2 丟失更新的現(xiàn)象

丟失更新是指2個(gè)或多個(gè)事務(wù)讀取同一數(shù)據(jù)并進(jìn)行修改，其中一個(gè)事務(wù)的修改結(jié)果破壞了另一個(gè)事務(wù)修改的結(jié)果。有兩類丟失更新：

1） A事務(wù)撤銷時(shí)，把已經(jīng)提交的B事務(wù)的更新數(shù)據(jù)覆蓋了。這種錯誤可能造成很嚴(yán)重的問題。A事務(wù)在撤銷時(shí)，“不小心”將B事務(wù)已經(jīng)轉(zhuǎn)入賬戶的金額給抹去了。

2） A事務(wù)覆蓋B事務(wù)已經(jīng)提交的數(shù)據(jù)，造成B事務(wù)所做操作丟失。由于轉(zhuǎn)賬事務(wù)覆蓋了取款事務(wù)對存款余額所做的更新，導(dǎo)致銀行最后損失了100元，相反如果轉(zhuǎn)賬事務(wù)先提交，那么用戶賬戶將損失100元。

在此過程中，買家A的“取消”訂單的動作，發(fā)生丟失。同時(shí)，對賣家造成了一定的經(jīng)濟(jì)損失。

如何防止買家A的“取消”動作不會丟失，或者賣家的“發(fā)貨”動作不會丟失呢？下面提出4種策略，加以證明。

4 防止丟失更新的策略

1） 設(shè)置數(shù)據(jù)庫的隔離級別為Serializable

當(dāng)是查詢操作的時(shí)候添加共享鎖，共享鎖下被人可以訪問同一條記錄；當(dāng)進(jìn)行修改操作的時(shí)候加排他鎖，別人不可以修改。內(nèi)在機(jī)制是異常退出機(jī)制。

賣家查詢訂單的時(shí)候，給這個(gè)訂單記錄添加了共享鎖，買家可以查看。同理，買家查看他的訂單的時(shí)候，也為自己的記錄添加了共享鎖，但共享鎖下不能再添加排他鎖。當(dāng)賣家想做修改操作（“發(fā)貨”）的時(shí)候，給這個(gè)訂單記錄添加一個(gè)排他鎖是加不上的，他需要等，等待買家釋放了共享鎖，也就是提交了事務(wù)，這個(gè)排它鎖才可以加上。但此時(shí)，如果買家也想操作這個(gè)訂單記錄，想給他的訂單記錄添加排他鎖，也是不可以的，因?yàn)橘u家那邊已經(jīng)有了共享鎖，買家想操作的話，也必須讓賣家去釋放這個(gè)共享鎖。這樣，賣家就要等買家，買家也要等賣家。假設(shè)，此時(shí)買家做了修改的操作，根據(jù)共享鎖存在的情況下，不能加排他鎖的原則，買家那里就會出現(xiàn)異常。此時(shí)這個(gè)“取消”操作終止，“取消”操作無效。就不會產(chǎn)生“取消”操作的丟失。

2） 悲觀鎖

一種進(jìn)行修改的時(shí)候，就給這條訂單記錄加鎖，別人就不能再操作了。悲觀鎖就是程序員認(rèn)為，客戶訪問某條記錄的時(shí)候，很有可能其他人也在訪問同條記錄。保險(xiǎn)起見，為這條訂單記錄加一把悲觀鎖，此時(shí)其他任何人都不可以修改這條記錄。這種鎖，適用于更新多查詢少的系統(tǒng)。

3） 樂觀鎖

樂觀鎖就是指當(dāng)買家或賣家要修改一條訂單記錄的時(shí)候，不認(rèn)為會有別人和自己同時(shí)操作這條訂單記錄?？衫弥辽賰煞N方式實(shí)現(xiàn)：

（1） 在訂單表中，添加一個(gè)version字段，數(shù)據(jù)類型為identity，表示版本

在修改的的時(shí)候利用版本號機(jī)制，那么別人的操作會因?yàn)榘姹咎柕牟町惗?。?dāng)?shù)谝淮尾僮鞯耐戤叺臅r(shí)候，這個(gè)版本號就自動加1，此時(shí)別人如果想要修改這條記錄的時(shí)候，會因?yàn)榘姹咎柕脑蚓筒荒茏鲂薷牧?。適用于查詢多更新少的系統(tǒng)。

（2） 在訂單表中，添加一個(gè)timestamp字段，數(shù)據(jù)類型也為timestamp時(shí)間戳（類似于郵局的郵戳）

時(shí)間戳列中存放的是一個(gè)十六進(jìn)制的數(shù)據(jù)，不管是買家或賣家的任何操作，都會產(chǎn)生一個(gè)唯一的時(shí)間戳值。在賣家“發(fā)貨”或買家“取消”訂單的時(shí)候，都會檢測時(shí)間戳值的值有沒有發(fā)生變化。如果不變，則繼續(xù)；反之，則操作不能進(jìn)行。

4） 通過IF語句搭配訂單狀態(tài)的檢查，也可防止丟失更新

（1） 假如買家想“取消”訂單，操作代碼如圖3。

（2） 假如賣家想為訂單“發(fā)貨”，操作代碼如圖4。

圖4 發(fā)貨

這樣，不管“取消”、“發(fā)貨”兩個(gè)動作發(fā)生的先后次序如何，均不會發(fā)生“取消”丟失，或“發(fā)貨”丟失。

5 結(jié)束語

在數(shù)據(jù)庫并發(fā)操作過程中，如果丟失更新的現(xiàn)象，數(shù)據(jù)庫開發(fā)人員在設(shè)計(jì)的時(shí)候，就能考慮全面，那么是完全能夠避免的。除

了程序控制外，還有許多工具也可以保護(hù)、避免這種情況，如Oracle Forms和HTML DB等。這些工具能確保：從查詢記錄的那個(gè)時(shí)刻開始，這個(gè)記錄沒有改變，而且對它執(zhí)行任何修改時(shí)都會將其鎖定。為了用戶的切身利益，作為一名數(shù)據(jù)庫開發(fā)者，將繼續(xù)研究丟失更新的現(xiàn)象，尋求更多的解決辦法。

參考文獻(xiàn)：

[1]（美）劉易斯.數(shù)據(jù)庫與事務(wù)處理[M]. 1版.北京：機(jī)械工業(yè)出版社，2005：537-547.

[2] 程云志.數(shù)據(jù)庫原理與SQL Server 2005應(yīng)用教程[M]. 1版.北京：機(jī)械工業(yè)出版社，2012：236-240.

[3] 蔣瀚洋，李月軍，龐婭娟.SQL Server 2005數(shù)據(jù)庫管理與開發(fā)教程[M]. 1版.北京：人民郵電出版社，2009：147-152.

[4] 陸琳，劉桂林.數(shù)據(jù)庫技術(shù)與應(yīng)用-SQL server 2005（應(yīng)用篇）[M]. 1版.長沙：中南大學(xué)出版社，2010：290-295.

[5] 呂鵬.數(shù)據(jù)庫更新丟失解決方案.IT/計(jì)算.[2011-08-10].

[6] 孟憲虎，馬雪英，鄧緒斌.大型數(shù)據(jù)庫管理系統(tǒng)技術(shù)、應(yīng)用與實(shí)例分析——基于SQL Server 2005[M]. 2版.北京：電子工業(yè)出版社，2011：119-137

[7] 李萍，黃可望，黃能耿.SQL Server 數(shù)據(jù)庫應(yīng)用及實(shí)訓(xùn)[M].1版.無錫職業(yè)技術(shù)學(xué)院，2014：96-102.endprint

摘要： 丟失更新（lost update）是一個(gè)經(jīng)典的數(shù)據(jù)庫問題，在多用戶計(jì)算機(jī)環(huán)境中存在。作為一名數(shù)據(jù)庫開發(fā)者，通過感同身受的例子，向大家展示何為丟失更新現(xiàn)象，并對這種現(xiàn)象進(jìn)行一定的研究。同時(shí)，提出幾種防止的策略。

關(guān)鍵詞：數(shù)據(jù)庫；丟失更新；防止策略

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2014）24-5593-02

Lost Update Phenomena of Research in the Database Concurrency Operations

ZHOU Wei

（Wuxi Institute of Technology， Wuxi 214121， China）

Abstract： Lost update is a classic database problem. It exists in a multi-user computer environment. As a database developer， through empathy example， to show what is lost update phenomenon， and conduct some research this phenomenon. Meanwhile， put forward several prevention strategies.

Key words： database； lost update； prevention strategies

1 概述

當(dāng)2個(gè)或多個(gè)用戶同時(shí)（時(shí)間上重疊）編輯同一行數(shù)據(jù)時(shí)會發(fā)生丟失更新，特別是在基于Web的應(yīng)用程序中常常出現(xiàn)。在實(shí)際運(yùn)行過程中，可能在幾天甚至幾個(gè)月中才會出現(xiàn)一次。這種現(xiàn)象只是隨機(jī)地、零星地出現(xiàn)，而且在受控環(huán)境中完全不可再生，對應(yīng)用程序是致命的。導(dǎo)致開發(fā)人員誤以為是用戶的錯誤，其實(shí)是開發(fā)人員在編寫應(yīng)用程序的時(shí)候，沒有處理好DML命令。

2 丟失更新的現(xiàn)象

丟失更新是指2個(gè)或多個(gè)事務(wù)讀取同一數(shù)據(jù)并進(jìn)行修改，其中一個(gè)事務(wù)的修改結(jié)果破壞了另一個(gè)事務(wù)修改的結(jié)果。有兩類丟失更新：

1） A事務(wù)撤銷時(shí)，把已經(jīng)提交的B事務(wù)的更新數(shù)據(jù)覆蓋了。這種錯誤可能造成很嚴(yán)重的問題。A事務(wù)在撤銷時(shí)，“不小心”將B事務(wù)已經(jīng)轉(zhuǎn)入賬戶的金額給抹去了。

2） A事務(wù)覆蓋B事務(wù)已經(jīng)提交的數(shù)據(jù)，造成B事務(wù)所做操作丟失。由于轉(zhuǎn)賬事務(wù)覆蓋了取款事務(wù)對存款余額所做的更新，導(dǎo)致銀行最后損失了100元，相反如果轉(zhuǎn)賬事務(wù)先提交，那么用戶賬戶將損失100元。

在此過程中，買家A的“取消”訂單的動作，發(fā)生丟失。同時(shí)，對賣家造成了一定的經(jīng)濟(jì)損失。

如何防止買家A的“取消”動作不會丟失，或者賣家的“發(fā)貨”動作不會丟失呢？下面提出4種策略，加以證明。

4 防止丟失更新的策略

1） 設(shè)置數(shù)據(jù)庫的隔離級別為Serializable

當(dāng)是查詢操作的時(shí)候添加共享鎖，共享鎖下被人可以訪問同一條記錄；當(dāng)進(jìn)行修改操作的時(shí)候加排他鎖，別人不可以修改。內(nèi)在機(jī)制是異常退出機(jī)制。

賣家查詢訂單的時(shí)候，給這個(gè)訂單記錄添加了共享鎖，買家可以查看。同理，買家查看他的訂單的時(shí)候，也為自己的記錄添加了共享鎖，但共享鎖下不能再添加排他鎖。當(dāng)賣家想做修改操作（“發(fā)貨”）的時(shí)候，給這個(gè)訂單記錄添加一個(gè)排他鎖是加不上的，他需要等，等待買家釋放了共享鎖，也就是提交了事務(wù)，這個(gè)排它鎖才可以加上。但此時(shí)，如果買家也想操作這個(gè)訂單記錄，想給他的訂單記錄添加排他鎖，也是不可以的，因?yàn)橘u家那邊已經(jīng)有了共享鎖，買家想操作的話，也必須讓賣家去釋放這個(gè)共享鎖。這樣，賣家就要等買家，買家也要等賣家。假設(shè)，此時(shí)買家做了修改的操作，根據(jù)共享鎖存在的情況下，不能加排他鎖的原則，買家那里就會出現(xiàn)異常。此時(shí)這個(gè)“取消”操作終止，“取消”操作無效。就不會產(chǎn)生“取消”操作的丟失。

2） 悲觀鎖

一種進(jìn)行修改的時(shí)候，就給這條訂單記錄加鎖，別人就不能再操作了。悲觀鎖就是程序員認(rèn)為，客戶訪問某條記錄的時(shí)候，很有可能其他人也在訪問同條記錄。保險(xiǎn)起見，為這條訂單記錄加一把悲觀鎖，此時(shí)其他任何人都不可以修改這條記錄。這種鎖，適用于更新多查詢少的系統(tǒng)。

3） 樂觀鎖

樂觀鎖就是指當(dāng)買家或賣家要修改一條訂單記錄的時(shí)候，不認(rèn)為會有別人和自己同時(shí)操作這條訂單記錄?？衫弥辽賰煞N方式實(shí)現(xiàn)：

（1） 在訂單表中，添加一個(gè)version字段，數(shù)據(jù)類型為identity，表示版本

在修改的的時(shí)候利用版本號機(jī)制，那么別人的操作會因?yàn)榘姹咎柕牟町惗А．?dāng)?shù)谝淮尾僮鞯耐戤叺臅r(shí)候，這個(gè)版本號就自動加1，此時(shí)別人如果想要修改這條記錄的時(shí)候，會因?yàn)榘姹咎柕脑蚓筒荒茏鲂薷牧?。適用于查詢多更新少的系統(tǒng)。

（2） 在訂單表中，添加一個(gè)timestamp字段，數(shù)據(jù)類型也為timestamp時(shí)間戳（類似于郵局的郵戳）

時(shí)間戳列中存放的是一個(gè)十六進(jìn)制的數(shù)據(jù)，不管是買家或賣家的任何操作，都會產(chǎn)生一個(gè)唯一的時(shí)間戳值。在賣家“發(fā)貨”或買家“取消”訂單的時(shí)候，都會檢測時(shí)間戳值的值有沒有發(fā)生變化。如果不變，則繼續(xù)；反之，則操作不能進(jìn)行。

4） 通過IF語句搭配訂單狀態(tài)的檢查，也可防止丟失更新

（1） 假如買家想“取消”訂單，操作代碼如圖3。

（2） 假如賣家想為訂單“發(fā)貨”，操作代碼如圖4。

圖4 發(fā)貨

這樣，不管“取消”、“發(fā)貨”兩個(gè)動作發(fā)生的先后次序如何，均不會發(fā)生“取消”丟失，或“發(fā)貨”丟失。

5 結(jié)束語

在數(shù)據(jù)庫并發(fā)操作過程中，如果丟失更新的現(xiàn)象，數(shù)據(jù)庫開發(fā)人員在設(shè)計(jì)的時(shí)候，就能考慮全面，那么是完全能夠避免的。除

了程序控制外，還有許多工具也可以保護(hù)、避免這種情況，如Oracle Forms和HTML DB等。這些工具能確保：從查詢記錄的那個(gè)時(shí)刻開始，這個(gè)記錄沒有改變，而且對它執(zhí)行任何修改時(shí)都會將其鎖定。為了用戶的切身利益，作為一名數(shù)據(jù)庫開發(fā)者，將繼續(xù)研究丟失更新的現(xiàn)象，尋求更多的解決辦法。

參考文獻(xiàn)：

[1]（美）劉易斯.數(shù)據(jù)庫與事務(wù)處理[M]. 1版.北京：機(jī)械工業(yè)出版社，2005：537-547.

[2] 程云志.數(shù)據(jù)庫原理與SQL Server 2005應(yīng)用教程[M]. 1版.北京：機(jī)械工業(yè)出版社，2012：236-240.

[3] 蔣瀚洋，李月軍，龐婭娟.SQL Server 2005數(shù)據(jù)庫管理與開發(fā)教程[M]. 1版.北京：人民郵電出版社，2009：147-152.

[4] 陸琳，劉桂林.數(shù)據(jù)庫技術(shù)與應(yīng)用-SQL server 2005（應(yīng)用篇）[M]. 1版.長沙：中南大學(xué)出版社，2010：290-295.

[5] 呂鵬.數(shù)據(jù)庫更新丟失解決方案.IT/計(jì)算.[2011-08-10].

[6] 孟憲虎，馬雪英，鄧緒斌.大型數(shù)據(jù)庫管理系統(tǒng)技術(shù)、應(yīng)用與實(shí)例分析——基于SQL Server 2005[M]. 2版.北京：電子工業(yè)出版社，2011：119-137

[7] 李萍，黃可望，黃能耿.SQL Server 數(shù)據(jù)庫應(yīng)用及實(shí)訓(xùn)[M].1版.無錫職業(yè)技術(shù)學(xué)院，2014：96-102.endprint