为什么 TransactionScope 不回滚分布式事务？
我正在使用名为 ECO 的对象持久性框架来将数据更新到 SQL Server。我注意到，如果我创建一个 TransactionScope，然后在第一个事务提交之后但在第二个事务提交之前故意抛出异常，则第一个数据库会更新，而第二个数据库不会更新。
我认为一旦分布式事务协调器在主数据库上运行，我只需围绕大量更新创建 TransactionScope 就可以了？
任何人都可以想到为什么这会允许更新第一个数据库但不更新第二个数据库的情况吗？
I am using an object persistence framework called ECO for updating data to SQL Server. I've noticed that if I create a TransactionScope and then deliberately throw an exception after my first transaction has committed but before my second has committed the first database is updated and the 2nd is not.
I thought that simply creating the TransactionScope around the numerous updates is all I had to do once the distributed transaction coordinator is running on the main DB?
Can anyone think of any reason why this would per permitting a scenario where the first DB is updated but not the second?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
知道了！
ECO 支持以下数据库...
今天早上我记得其中一些不支持连接池，因此在抽象 PersistenceMapper 类上 ECO 有实现了自己的连接池。这就是发生的事情
因此，该连接未登记在当前的分布式事务中。考虑到 SqlConnection 进行自己的池化，将 PersistenceMapperSqlServer.MaxPoolSize 设置为 0 是可以接受的。
现在它使用 SqlConnection 组件来处理连接的创建/销毁，该组件不仅池化连接，而且还正确处理分布式事务！
我已写信给开发人员，让他们知道他们应该将此属性标记为过时。
Got it!
ECO supports the following databases...
I remembered this morning that some of these don't support connection pooling, so on an abstract PersistenceMapper class ECO has implemented its own connection pooling. This is what was happening
As a consequence the connection is not enlisted in the current distributed transaction. Considering SqlConnection does its own pooling it was acceptable to set PersistenceMapperSqlServer.MaxPoolSize to ZERO.
Now it uses the SqlConnection component to deal with the creation/disposal of Connections, not only does that component pool the connections but it also deals with distributed transactions properly too!
I've written to the developers to let them know that they should mark this property obsolete.