事務剖析

事務最基本上包含兩個步驟 – 開始, 然后是提交或回滾. 開始調用定義了事務的邊界, 同時調用提交或回滾在定義結束. 在事務邊界內, 所有的執行描述被認為是完成任務的一部分, 必須作為成功或失敗的一種. 如果一切都成功提交將會執行所有的數據修改, 如果有任何錯誤發生, 回滾將會取消修改. 所有的.Net 數據提供對象提供了類似的類和方法來完成這些操作.

孤立等級

孤立等級在事務中界定事務孤立行為. 越是孤立等級越高, 數據越不會被別的事務干擾. 許多數據庫通過加鎖來增強孤立等級. 你應該實行兩次檢查你目標DBMS使用.好的做法是在性能和并發上折衷, 較多的鎖系統將不得不維護, 越多的話容易造成沖突并且會降低速度對于不同的處理來說.

以下列表是孤立等級對于ADO.Net的支持, 來自于.Net Framewok SDK. 以下列表孤立等級限制性越來越強.



Member name
Description
Value

Unspecified

Supported by the .NET Compact Framework.
A different isolation level than the one specified is being used, but the level cannot be determined.
-1

Chaos

Supported by the .NET Compact Framework.
The pending changes from more highly isolated transactions cannot be overwritten.
16

ReadUncommitted

Supported by the .NET Compact Framework.
A dirty read is possible, meaning that no shared locks are issued and no exclusive locks are honored.
256

ReadCommitted

Supported by the .NET Compact Framework.
Shared locks are held while the data is being read to avoid dirty reads, but the data can be changed before the end of the transaction, resulting in non-repeatable reads or phantom data.
4096

RepeatableRead

Supported by the .NET Compact Framework.
Locks are placed on all data that is used in a query, preventing other users from updating the data. Prevents non-repeatable reads but phantom rows are still possible.
65536

Serializable

Supported by the .NET Compact Framework.
A range lock is placed on the data set, preventing other users from updating or inserting rows into the dataset until the transaction is complete.
1048576



小注: 無序的孤立等級是不被SQL Server 或 Oracle 支持的, 只有OLEDB 數據提供對象將會作為孤立等級設置事務接受它. 如果試圖用SQL Server 或Oracle 設置它,將會得到一個ArgumentException, 指明無效的孤立等級參數.

Sql Server 和 Oracle 和 OLE DB 數據提供對象默認為ReadCommitted 孤立等級. ODBC 數據提供對象默認孤立等級各不相同, 依賴于ＯＤＢＣ的驅動的不同．　如果你考慮ReadCommitted　不是你想要的孤立等級，　你可以使用Transaction.IsolationLevel　屬性來　指定不同的等級．　你應該非常慎重考慮修改這些設置，雖然，　執行適當的測試來保證，這些變化不能影響數據的一致性，或其它的并發問題．　如果有數據庫管理員，　你應該向他們請教關于特定任務的恰當等級．你也應該查看數據庫文檔來看你的數據庫是如何處理孤立等級和鎖的．

局部回滾

通常情況下，如果一個事務發生錯誤，你會發現你想回滾的地方并不是整個事務．只有當你完全成功處理完某個事務需要大量的時間時，你希望會這樣做．　但檢查部分執行成功將會開銷很大．　你要平衡數據修改成本和不得不回滾一些小的的部分來避免開支過大．

部分回滾通常使用savepoints或者是內嵌事務，　主要依賴于你的數據庫是如何工作的．　一些ＤＢＭＳ　或者不提供這種機制，因此查看你的數據庫文檔看是否或如何實現局部回滾．

Sql Server 和　Oracle　允許使用　savepoints （當造成回滾時你可以引用）來停止回滾在預定的點．他們不真正的執行內嵌的事務，另外的一些ＤＢＭＳｓ來完成同樣的工作．　Ｓｑｌ Server　在最簡單的意義上允許使用內嵌的事務，　你可以使用內嵌的開始．．．提交Ｔ－Ｓｑｌ塊語句．然而，　只有在提交以外事實上提交了所有的事務，在提交過程以內僅僅是消耗系統變量，因此你可以跟蹤多少事務你有多少已經打開的事務．

一些數據庫執行了真正的內嵌事務．　對這些數據類型來說，內嵌的提交將會實際上提交響應的事務，即使外部的事務回滾內嵌事務仍然會提交．