为什么TransactionScope不回滚分布式事务？

Question

我使用名为ECO的对象持久性框架来将数据更新到SQL Server。我注意到，如果我创建一个TransactionScope，然后在我的第一个事务提交之后但在第二个提交之前故意抛出异常，则第一个数据库被更新而第二个数据库没有更新。

我认为只要在主数据库上运行分布式事务协调器，我就必须围绕众多更新创建TransactionScope吗？

任何人都可以想到为什么这会允许更新第一个数据库而不是第二个数据库的情况？

Answer 1

知道了！

ECO支持以下数据库......

1. 黑鱼
2. DB2
3. 火鸟
4. Mimer
5. MySQL的
6. NexusDB
7. 甲骨文
8. SQLite的
9. SQLServer的
10. 的Sybase
11. Borland数据提供商
12. Borland数据库eXpress（DBX）

我记得今天早上其中一些不支持连接池，因此在抽象的PersistenceMapper类中，ECO已经实现了自己的连接池。这就是发生的事情

1. 应用程序启动
2. 我选择将对象映射信息存储在数据库本身中，因此ECO获取连接并读取该映射信息
3. ECO返回与池的连接，但其OWN池
4. 我后来开始分发交易
5. 我将对象更新到数据库
6. ECO从其自己的池中检索连接

因此，连接不会在当前的分布式事务中登记。考虑到SqlConnection有自己的池，可以将PersistenceMapperSqlServer.MaxPoolSize设置为ZERO。

现在它使用SqlConnection组件来处理Connections的创建/处理，不仅该组件汇集连接，而且它也正确地处理分布式事务！

我写信给开发人员让他们知道他们应该将这个属性标记为过时。