具有不同IsolationLevel的內部TransactionScope，它如何實現？

的當前實現TransactionScope缺少在嵌套作用域中更改IsolationLevel的能力。具有不同IsolationLevel的內部TransactionScope，它如何實現？

MSDN states：當使用嵌套的TransactionScope對象時，如果想要加入環境事務，則必須將所有嵌套的作用域配置爲使用完全相同的隔離級別。如果嵌套的TransactionScope對象嘗試連接環境事務，但它指定了不同的隔離級別，則會引發一個ArgumentException。

但是，SQL Server允許我們隨時更改隔離級別，爲什麼TransactionScope不允許？我不明白。

BCL中是否存在關於嵌套SQL事務及其隔離級別的任何標準以禁止此行爲。我有什麼選擇？我當然不能設計類庫，只是爲了可以使用它們而提升隔離級別。

如果方法A（）想要一個快照水平並調用希望讀已提交水平的方法B（）。方法A（）在我開發的LibraryA中，方法B（）位於由虛構公司開發的LibraryB中。如何A（）致電B（）沒有得到ArgumentException？

這是比任何特定產品更理論的問題。基本上，交易的原始概念是具有所有ACID屬性的東西：原子，一致，隔離和耐久。現在

，考慮什麼是「隔離級別」的意思是：本質上，性能或其他原因，我們可能會選擇放棄部分或全部保證數據庫提出了關於酸度。隔離和原子性密切相關，就像是彼此的雙重關係。打破一個，另一個受苦。

將事務分解成可在特定SQL語句中單獨表達的部分是很常見的，但爲了您的保證可以提供幫助，您需要將它們包裝在事務中，並至少爲整個Shmear提供足夠的隔離好好工作。

現在，如果您的交易的某個部分需要更大程度的隔離，那麼整個交易也會發生，否則它可能會在敏感部分中斷。相反，如果某個部分的隔離水平較低，那麼很可能該部分的適當功能需要較少的隔離。（不要問我拿出一個很好的例子，當這可能是真的。）

無論如何，數據庫服務器沒有辦法告訴實際需求是否兼容，所以它放棄了這個問題。

真正應該發生的事情是人們開發他們需要的交易。我意識到這並非易事，但鑑於您的業務數據模式是您自己的事實，因此將隨機SQL組件組合在一起並不容易。

在處理集中式數據庫（如SQL Server）的情況下，最好的做法是設計整個事務，然後當您注意到設計之間的通用性時，可以在編寫毛茸茸的代碼之前將其排除。

如果您確實需要在不同的數據存儲庫（或類似的數據存儲庫）之間進行協調，則需要分佈式事務管理器。它是一個獨立的產品，比數據庫服務器更難獲得。但是，這對於像自動取款機這樣的東西是必要的，這些東西要麼是給你錢，要麼是你的銀行帳戶，或者不是，而且這兩者必須匹配。

祝你好運！

2010-08-24 14:39:29 Ian

感謝您的答覆。但我缺少的是爲什麼如果SQL Server允許更改事務的隔離級別，那麼框架會禁止它？有時候，你可能真的需要這個用於一些具有優化目的的子語句，而且我真的不想用自己的SQL語句來改變它的級別。 – 2010-08-25 06:54:42

@IvanZlatanov TransactionScope不限於與SQL Server一起使用，它可以允許跨進程/系統的分佈式事務。因此它比SQL Server允許的更嚴格，可能會簡化確保整個系統一致性的複雜性，而不是支持分佈式事務。 – AaronLS 2013-05-24 20:49:23

@AaronLS永遠不要這樣想。非常有意義。 – 2013-05-27 07:54:32

我發現自己陷入了這個麻煩，一旦我猜想異常選項會將所有的東西都分解出來，並且你不能完成這些事情，而是可以做類似的事情。事實是，如果切換隔離級別，每個連接只允許一個隔離級別整個隔離級別會改變直到嵌套完成。

退房this stackpost

2015-10-12 01:53:11 GoAntonio

回答