.NET TransactionScope与MSDTC异常相关问题咨询

让我逐个拆解你的问题，结合Entity Framework和System.Transactions的工作原理来解释：

1. 为何最初的事务代码从未抛出该异常？ #

这背后的核心是连接池的复用机制和本地事务（LTM）的工作逻辑。

你最初的代码里，repo1.SaveSomething()和repo2.SaveAnythingElse()各自创建并释放DbContext，但因为两个DbContext使用的是完全相同的连接字符串，当第一个DbContext的连接关闭后，这个连接会被放回ADO.NET的连接池里。第二个DbContext打开连接时，连接池会直接分配这个已存在的物理连接，而不是创建新的。

此时，System.Transactions的事务管理器（LTM，轻量级事务管理器）会把这个复用的连接纳入同一个本地事务中，不需要调用MSDTC（分布式事务协调器）。只要事务范围内只有一个物理连接，就不会触发分布式事务，自然也就不会出现MSDTC相关的异常。

2. 新增代码后为何会触发异常？ #

新增的代码打破了「连接复用」的前提，导致事务管理器不得不将本地事务升级为分布式事务，而你的环境中MSDTC的网络访问是禁用的，所以抛出了异常。可能的原因包括：

• 连接字符串不一致：新增的代码里可能使用了看似相同但实际有差异的连接字符串（比如多了空格、参数顺序不同、用户名/密码细微变化，甚至只是大小写不同），连接池会把这些视为不同的连接，从而创建新的物理连接；
• 连接池无可用连接：新增的操作可能在事务范围内打开了更多连接，或者连接的释放时机被改变，导致连接池无法提供可复用的连接，只能创建新的物理连接；
• 事务行为的隐性变化：新增的代码可能触发了某些Entity Framework的特性（比如延迟加载、跨上下文操作），间接导致了新的物理连接被打开。

当事务范围内出现多个物理连接时，LTM无法处理，就会自动升级为需要MSDTC参与的分布式事务。而你的系统中MSDTC的网络访问被禁用，就会抛出你看到的异常。

3. 修改代码后异常为何不再出现？ #

你修改的关键是显式设置了事务的隔离级别为ReadCommitted，同时明确指定了TransactionScopeOption.Required（虽然默认就是Required，但显式配置会改变事务的初始化逻辑）。

原来的TransactionScope默认隔离级别是Serializable，这是最严格的隔离级别。在Serializable事务下，SQL Server的连接会持有更持久的锁定，导致连接关闭后无法立即被连接池复用——也就是说，第二个DbContext打开连接时，连接池无法提供之前的连接，只能创建新的物理连接，进而触发事务升级。

当你改为ReadCommitted隔离级别后：

• 连接的锁定会更快释放，连接关闭后可以立即回到连接池；
• 后续的DbContext可以复用同一个物理连接，事务始终保持在LTM的本地事务范围内，不需要调用MSDTC，因此异常就消失了。

另外，显式配置TransactionOptions也让事务的行为更明确，避免了默认Serializable级别带来的隐性事务升级风险。

内容的提问来源于stack exchange，提问作者Zoltan Hernyak