資料併發問題收藏
我在部落格堂上也看到不少有關併發控制的文章,我一直是推薦使用時間戳來解決的。
比如我們在SQL Server中的表中定義一個欄位為timestamp型別的欄位ts,這個欄位的值不需要我們進行控制的。
在Insert與Update時,資料庫會自己進行ts值的更新,因此我們只要在Update時使用:
Update xxx where key=@key and ts=@ts 就可以了,根本不用考慮ts裡的值更新。
Delete時也最好進行一下判斷,用這種方式是可以控制資料併發操作的。
只需要在Update與Delete時,判斷"影響條數"就可以知道更新是否成功。
這一點我想非常方便,但不是所有的資料庫都支援timestampr的,如在Access裡沒有timestamp欄位,我也不知道其他的資料庫是否都有類似的timestamp型別, 不管怎麼樣,我覺得我們不能完全信賴於資料庫的控制,而應該採用自設的控制機制,這樣可以適應系統的資料庫移值,下面我就介紹一下,在.NET下如何實現,自設的時間戳控制。
我們也同樣建一個欄位ts,定義為Varchar,長度在20以上即可,而且不允許為null,這樣比較合適。
我們應該採用什麼機制來生成隨時的或者說不可能會產生一樣的值,我推薦的是DateTime.Now.Ticks,這是一個12位的數字,由於在Update等更新時,資料庫會自動進行鎖定,所以不可能會在同一時間會有兩個一樣的操作執行,因此這就可以避免Ticks產生相同的值了。
或者也可以採用Guid值,也可以產生唯一值,但我覺得Guid值太大,可能會影響效率。
那好,在我們Insert時:Insert xxxx ts='221283747584' where key='1'
在Update時 Update xx set xxx ts='39383848593839' where key='1' and ts='111111111111' //假設取到的原值為'11111111111'
Delete類似上面的。
我們判斷影響條數,如果為0則說明更新不成功。
我相信上面的方法是簡單可行的。
我目前也遇到一個問題:如果是批量更新與批量刪除,如何進行併發控制呢?
由於批量更新時,不是一條記錄:Update xxx where Birthday='2004-2-1'之類的,會影響到N條資料,要進行併發控制就不那麼容易了。如果還是採用一條條判斷ts那是不現實的。
對於這種只能放棄併發控制嗎?
比如我們在SQL Server中的表中定義一個欄位為timestamp型別的欄位ts,這個欄位的值不需要我們進行控制的。
在Insert與Update時,資料庫會自己進行ts值的更新,因此我們只要在Update時使用:
Update xxx where key=@key and ts=@ts 就可以了,根本不用考慮ts裡的值更新。
Delete時也最好進行一下判斷,用這種方式是可以控制資料併發操作的。
只需要在Update與Delete時,判斷"影響條數"就可以知道更新是否成功。
這一點我想非常方便,但不是所有的資料庫都支援timestampr的,如在Access裡沒有timestamp欄位,我也不知道其他的資料庫是否都有類似的timestamp型別, 不管怎麼樣,我覺得我們不能完全信賴於資料庫的控制,而應該採用自設的控制機制,這樣可以適應系統的資料庫移值,下面我就介紹一下,在.NET下如何實現,自設的時間戳控制。
我們也同樣建一個欄位ts,定義為Varchar,長度在20以上即可,而且不允許為null,這樣比較合適。
我們應該採用什麼機制來生成隨時的或者說不可能會產生一樣的值,我推薦的是DateTime.Now.Ticks,這是一個12位的數字,由於在Update等更新時,資料庫會自動進行鎖定,所以不可能會在同一時間會有兩個一樣的操作執行,因此這就可以避免Ticks產生相同的值了。
或者也可以採用Guid值,也可以產生唯一值,但我覺得Guid值太大,可能會影響效率。
那好,在我們Insert時:Insert xxxx ts='221283747584' where key='1'
在Update時 Update xx set xxx ts='39383848593839' where key='1' and ts='111111111111' //假設取到的原值為'11111111111'
Delete類似上面的。
我們判斷影響條數,如果為0則說明更新不成功。
我相信上面的方法是簡單可行的。
我目前也遇到一個問題:如果是批量更新與批量刪除,如何進行併發控制呢?
由於批量更新時,不是一條記錄:Update xxx where Birthday='2004-2-1'之類的,會影響到N條資料,要進行併發控制就不那麼容易了。如果還是採用一條條判斷ts那是不現實的。
對於這種只能放棄併發控制嗎?
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/16436858/viewspace-609111/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料庫併發問題資料庫
- 求助:資料庫併發訪問問題資料庫
- 併發查詢資料庫問題資料庫
- 資料編號+1 併發問題解決
- 解決資料庫高併發訪問瓶頸問題資料庫
- oracle併發問題Oracle
- 使用資料庫處理併發可能導致的問題資料庫
- 資料庫之事務、隔離級別和併發問題資料庫
- 請教老師關於 高併發插入資料問題
- mysql併發操作問題MySql
- 資料併發操作帶的的問題及解決辦法
- Android中Sqlite資料庫多執行緒併發問題AndroidSQLite資料庫執行緒
- 請教資料庫併發訪問的問題!望各位大蝦指點!資料庫
- 優步爆Go語言容易發生的資料併發爭奪問題Go
- 資料庫併發寫入問題-丟失更新與寫入偏差資料庫
- 高併發下資料冪等問題的9種解決方案
- 併發問題處理方式
- Java之併發三問題Java
- 併發執行hang問題
- 併發處理中的問題以及解決這些問題的併發模型模型
- 【Golang】淺談協程併發競爭資源問題Golang
- 資料訪問模式:資料併發控制(Data Concurrency Control)模式
- 【Java併發程式設計】併發程式設計大合集-值得收藏Java程式設計
- 資料庫事務 ACID屬性、資料庫併發問題和四種隔離級別資料庫
- mysql 高併發 select update 併發更新問題解決方案MySql
- 【資料庫】併發控制資料庫
- 併發技術5:死鎖問題
- PHP Session可能會引起併發問題PHPSession
- 一個併發事件的阻塞問題事件
- 資料庫事務併發問題----各種事務隔離下的情況資料庫
- 【眼見為實】資料庫併發問題 封鎖協議 隔離級別資料庫協議
- SQL Server 2005 管理併發資料訪問[zt]SQLServer
- 探索併發程式設計(七)——分散式環境中併發問題程式設計分散式
- 資料庫事務併發產生的問題以及事務的隔離級別資料庫
- [分散式]高併發案例---庫存超發問題分散式
- 併發請求的重複插入問題
- 用分散式鎖解決併發問題分散式
- 高併發快取面臨的問題快取