的当前执行情况交易范围 缺乏在嵌套范围内更改 IsolationLevels 的能力。
MSDN状态:当使用嵌套的 TransactionScope 对象时，所有嵌套的作用域必须配置为使用完全相同的隔离级别，如果它们想加入环境事务。如果嵌套的 TransactionScope 对象尝试加入环境事务但它指定了不同的隔离级别，则 参数异常 被抛出。
但是 SQL Server 允许我们随时更改隔离级别，为什么 TransactionScope 不允许？我不明白。
BCL 中是否有任何关于嵌套 SQL 事务及其隔离级别的标准禁止这种行为。我有哪些选择？我当然不能仅仅为了它们可以使用而设计类库并与它们一起推广隔离级别。
如果方法 A() 想要一个 快照 级别并调用想要 的方法 B()读已提交 等级。方法 A() 在我开发的 LibraryA 中，方法 B() 位于由一家虚构公司开发的 LibraryB 中。怎么可以 A() 调用 B() 没有得到参数异常 ?
最佳答案
这更像是一个理论问题，而不是任何特定产品。基本上，事务的原始概念具有所有 ACID 属性:原子性、一致性、隔离性和持久性。
http://databases.about.com/od/specificproducts/a/acid.htm
现在，考虑一下“隔离级别”的含义:本质上，出于性能或其他原因，我们可能会选择放弃数据库对 ACIDity 做出的部分或全部保证。隔离性和原子性密切相关，就像彼此的双重关系。打破一个，另一个受苦。
将事务分解为可以在特定 SQL 语句中单独表达的部分是很常见的，但是为了保证有帮助，您需要将它们包装在一个事务中，至少要有足够的隔离以使整个 shmear 正常工作。
现在，如果您的事务的某些部分需要更大程度的隔离，那么整个事务也需要，否则它可能会在敏感部分中断。相反，如果某个部件的隔离级别较低，则该部件的正常功能很可能需要较少的隔离。 (不要让我想出一个很好的例子来说明什么时候这可能是真的。)
无论如何，数据库服务器无法判断实际需求是否兼容，因此它完全放弃了这个问题。
真正应该发生的是人们开发他们需要的交易。我意识到这并不总是那么容易，但鉴于您的业务数据架构是您自己的，因此将随机 SQL 组件插入在一起并不容易。
在处理集中式数据库(如 SQL Server)的情况下，最佳实践是设计整个事务，然后当您注意到设计之间的共性时，您可以在编写繁琐的代码之前将其分解。
如果您确实需要在不同的数据存储库(或类似存储库)之间进行协调，则需要分布式事务管理器。它是一个单独的产品，比数据库服务器更难做到正确。但这对于 ATM 之类的东西来说是必要的，它要么给你钱，要么不给你钱，要么打你的银行账户，要么不打，这两者必须匹配。
祝你好运!
关于.net - 不同IsolationLevel的Inner TransactionScope，如何实现？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3557435/