事務(wù)剖析
事務(wù)最基本上包含兩個步驟 – 開始, 然后是提交或回滾. 開始調(diào)用定義了事務(wù)的邊界, 同時調(diào)用提交或回滾在定義結(jié)束. 在事務(wù)邊界內(nèi), 所有的執(zhí)行描述被認為是完成任務(wù)的一部分, 必須作為成功或失敗的一種. 如果一切都成功提交將會執(zhí)行所有的數(shù)據(jù)修改, 如果有任何錯誤發(fā)生, 回滾將會取消修改. 所有的.Net 數(shù)據(jù)提供對象提供了類似的類和方法來完成這些操作.
孤立等級
孤立等級在事務(wù)中界定事務(wù)孤立行為. 越是孤立等級越高, 數(shù)據(jù)越不會被別的事務(wù)干擾. 許多數(shù)據(jù)庫通過加鎖來增強孤立等級. 你應(yīng)該實行兩次檢查你目標(biāo)DBMS使用.好的做法是在性能和并發(fā)上折衷, 較多的鎖系統(tǒng)將不得不維護, 越多的話容易造成沖突并且會降低速度對于不同的處理來說.
以下列表是孤立等級對于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 數(shù)據(jù)提供對象將會作為孤立等級設(shè)置事務(wù)接受它. 如果試圖用SQL Server 或Oracle 設(shè)置它,將會得到一個ArgumentException, 指明無效的孤立等級參數(shù).
Sql Server 和 Oracle 和 OLE DB 數(shù)據(jù)提供對象默認為ReadCommitted 孤立等級. ODBC 數(shù)據(jù)提供對象默認孤立等級各不相同, 依賴于ODBC的驅(qū)動的不同. 如果你考慮ReadCommitted 不是你想要的孤立等級, 你可以使用Transaction.IsolationLevel 屬性來 指定不同的等級. 你應(yīng)該非常慎重考慮修改這些設(shè)置,雖然, 執(zhí)行適當(dāng)?shù)臏y試來保證,這些變化不能影響數(shù)據(jù)的一致性,或其它的并發(fā)問題. 如果有數(shù)據(jù)庫管理員, 你應(yīng)該向他們請教關(guān)于特定任務(wù)的恰當(dāng)?shù)燃墸阋矐?yīng)該查看數(shù)據(jù)庫文檔來看你的數(shù)據(jù)庫是如何處理孤立等級和鎖的.
局部回滾
通常情況下,如果一個事務(wù)發(fā)生錯誤,你會發(fā)現(xiàn)你想回滾的地方并不是整個事務(wù).只有當(dāng)你完全成功處理完某個事務(wù)需要大量的時間時,你希望會這樣做. 但檢查部分執(zhí)行成功將會開銷很大. 你要平衡數(shù)據(jù)修改成本和不得不回滾一些小的的部分來避免開支過大.
部分回滾通常使用savepoints或者是內(nèi)嵌事務(wù), 主要依賴于你的數(shù)據(jù)庫是如何工作的. 一些DBMS 或者不提供這種機制,因此查看你的數(shù)據(jù)庫文檔看是否或如何實現(xiàn)局部回滾.
Sql Server 和 Oracle 允許使用 savepoints (當(dāng)造成回滾時你可以引用)來停止回滾在預(yù)定的點.他們不真正的執(zhí)行內(nèi)嵌的事務(wù),另外的一些DBMSs來完成同樣的工作. Sql Server 在最簡單的意義上允許使用內(nèi)嵌的事務(wù), 你可以使用內(nèi)嵌的開始...提交T-Sql塊語句.然而, 只有在提交以外事實上提交了所有的事務(wù),在提交過程以內(nèi)僅僅是消耗系統(tǒng)變量,因此你可以跟蹤多少事務(wù)你有多少已經(jīng)打開的事務(wù).
一些數(shù)據(jù)庫執(zhí)行了真正的內(nèi)嵌事務(wù). 對這些數(shù)據(jù)類型來說,內(nèi)嵌的提交將會實際上提交響應(yīng)的事務(wù),即使外部的事務(wù)回滾內(nèi)嵌事務(wù)仍然會提交.
|