用Microsoft.net實現數據庫事務(四)
2024-07-10 13:03:30
供稿：網友
中國最大的web開發資源網站及技術社區，
附a：事務簡介
一個事務是一系列動作作為單個邏輯單位來執行，這意味著這些動作要么全部成功，要么全部失敗。如果最后一個動作失敗了，那么以前的動作應該依次回滾，整個狀態回到原先事務開始的狀態。例如，有1000美圓從一個銀行帳戶扣除，轉入另外一個帳戶，那么事務保證兩個事件只能一起成功，只要有一個失敗，那么實際就不會發生任何動作，兩個帳戶沒有發生任何改變，錢沒有被存入和扣除。
acid屬性
有四個屬性經常被用來描述事務：原子性（atomicity）, 一致性（consistency）, 隔離性（isolation）, 持久性（durability）。在一個理想的環境里，事務符合這四個標準，但是一個事務的隔離級別是可以設置的，原因是設置一個事物的隔離級別為最佳的“可序列化”會增加一種被稱為“死鎖“情況發生的機率。死鎖是兩個事務試圖去鎖住已經被對方鎖住的資源，最后一個事務需要回滾，這樣另外一個才得以繼續。為了避免這樣的情況發生，你要求降低一個事務的隔離級別來減低它的爭奪力。
l 原子性：事務要作為一個原子單位工作，要不全部執行成功，要么全部失敗
l 一致性：事務結束后需要保持所有數據的一致性，在一個關系數據庫里，所有的規則要發生在事務引起的變動上，來保持數據的一致性，所有的內部數據結構，如b-tree索引、雙向聯結必須在事務結束后保持正確。
l 隔離性：并發事務所作出的變動必須和其他任何并發事務做的變更相隔離。一個事務要么看到其他事務更改它之前的數據，要么看到其他事務更改之后的數據，它不能看到臨時的數據，。。。。。。
l 持久性：一個事務結束后，它的結果會持久地存在與系統中，它的變動甚至在系統癱瘓時候也會存在。
事務支持級別
支持級別
描述
隔絕
忽略事務環境
不支持
對象或者頁面不運行在事物環境中. 請求來到時候，不管是否有激活的事務存在，對象的上下文被創建為非事務類型。
支持
對象或者頁面運行在已有的事務環境中，如果環境沒有事務，則不以事務形式運行。
需要
對象或者頁面運行在已有的事務環境中，如果環境沒有事務，則會創建一個新的。
需要新的
對象或者頁面需要一個事務，每次請求都將創建一個新的事務。
表2：事務支持級別
對于asp.net，頁面的默認事務級別是“隔絕”，在企業級服務里面默認級別是“需要”，一般地，我們會在需要事務的第一層對象上設置級別為“需要”，被調用的對象設置為“支持”。這意味著頂層的對象會創建一個事務，每個被調用的對象被激活時，將進入這個事務的上下文中。
事務隔離級別
在一個程序中，依據事務的隔離級別將會有三種情況發生。
l 臟讀：一個事務會讀進還沒有被另一個事務提交的數據，所以你會看到一些最后被另一個事務回滾掉的數據。
l 讀值不可復現：一個事務讀進一條記錄，另一個事務更改了這條記錄并提交完畢，這時候第一個事務再次讀這條記錄時，它已經改變了。
l 幻影讀：一個事務用where子句來檢索一個表的數據，另一個事務插入一條新的記錄，并且符合where條件，這樣，第一個事務用同一個where條件來檢索數據后，就會多出一條記錄。
支持級別
描述
讀入未提交的
最低的隔離級別，這個級別的事務存在臟讀、讀值不復現和幻影讀情況。
讀入提交的
許多數據庫的缺省級別，這個級別上你可能遇到讀值不可復現和幻影讀的情況。
可重復讀的
這個級別會遇到幻影讀。
可序列化的
事務之間完全隔離，在com+ 1.0中，這是唯一選項，但在 com+ 1.5中，是只是選項之一.
表3：事務隔離級別
一個事務所選擇的隔離級別影響著數據庫怎樣對待其他事務擁有的鎖，你所選擇的隔離級別依賴于你的系統和商務邏輯。例如，一個銀行在客戶取錢之前會檢查它的帳戶余額，這種情況下，就需要一個隔離級別為可序列化的事務，這樣另外一個取錢動作在這次完成之前將不能執行。如果它們僅需要提供一個帳戶余額，“讀提交的“將是合適的級別，因為他們僅需要查詢余額的值，級別的降低會使事務運行更快。
附b 事務開發的建議
l 在一定負荷下面測試事務控制器來保證負荷下死鎖不會發生
l 盡可能使用存儲過程，它們在各種情況仍擁有最好的性能
l 企業級服務為事務的控制提供了一個高級的方式，但使用要謹慎，因為它使性能降低
l 分析你的系統，來決定使用哪一種隔離級別的事務。銀行系統應該使用可序列化的隔離級別
附c 監控事務
沒有一種特別的機制來追蹤數據庫事務和ado.net事務。
asp.net和企業級服務的事務可以被控制臺的組件服務程序來監控，組件服務在開始菜單的管理工具中可以找到。從這個工具中,你可以監控所有通過ms dtc來運行的事務，也就是asp.net和企業級服務的事務。你也可以監視事務的執行時間，甚至事務提交、回滾、取消的整個過程。
附d 死鎖
當兩個或兩個以上進程（或線程）互相擁有對方需要的鎖，就會發生死鎖，一般是在數據庫系統中，但也可能發生在任何的多線程程序中，比如：
事務1
事務 2
鎖定表a
鎖定表b
更新表 a
更新表 b
試圖鎖定表 b
試圖鎖定表 a
在這個時刻，兩個事務都不能繼續進行，因為它們都試圖鎖定對方已經鎖定的資源，并且根據事務的規則，兩個事務都不能得知對方的狀態。sql server會檢測到這種情況的發生，會選擇其中的一個回滾，這樣起碼有一個事務可以正常完成了。在這個時刻，控制哪個事務被犧牲的程序不得不決定是重啟這個事務還是拋出錯誤給用戶。一般地，sql server會犧牲那個后開始的事務，或者是可以解開最多死鎖的那個事務。
死鎖中的一個問題是數據庫會自動做一個回滾，這樣會引起中間層的回滾代碼里的一個問題，如果你遇到一個死鎖，并且在中間層可以截獲異常，當中間層進行回滾的時候會得到另外一個異常，這樣你就產生了第二個異常，這是因為sql server已經為你做了一次回滾，所以你實際上是進行了第二次回滾，這時sql server卻找不到可以回滾的事務。所以一個良好的習慣是把回滾的代碼放到一個try catch里面，或者把這個異常匹配到sqlexception，并且檢測sqlexception異常的代碼，如果是1205，那么就是死鎖的情況發生了。
例如：
try
{
// run sql commands in ado.net transaction
catch (sqlexception sqlex)
{
// specific catch for deadlock
if (sqlex.number != 1205)
{
tx.rollback();
}
orderid = 0;
throw(sqlex);
}
避免死鎖的方法
有幾個方法可以降低事務發生死鎖的幾率
l 試圖在事務中用同樣的順序去訪問表，在前面的例子中，如果兩個事務都先訪問表a后訪問表b，那么就可以避免死鎖，兩個事務都能成功。
l 避免在事務中有用戶參與/盡量是事務短小，運行時間長的事務會增加和其他事務發生死鎖的機會，在存儲過程中運行事務可能會用最短的時間。
l 用一個低的隔離級別，把你的事務的隔離級別設置為最低會使你的業務降低發生死鎖的風險，缺省的，sql server把隔離級別設置為“讀取提交的”，這意味著如果一個事務為了讀而鎖定一些數據，另外一個事務允許鎖定它去讀、寫、刪除和更改，這樣會產生“幻影讀“的情況，但在一般的業務中是可以接受的。
l 使用bound connections，在這種條件下，兩個連接共享一個事務/鎖空間，從而避免鎖的沖突。
