TransactionScope：情况变得更好了吗？
当 TransactionScope 首次推出时，我在让它在我的开发机器 (XP) 和我们的数据库服务器 (Windows Server 2003) 之间工作时遇到了一些严重的问题。
当我进一步研究时，这似乎是一个棘手且普遍的问题，有可能在生产中成为令人头痛的问题，因此我决定不以这种方式处理事务（尽管我非常喜欢这种语法并且我真的很想要它）上班）。
这些问题是否仍然存在或者可以安全使用吗？ 您现在经常使用它没有问题吗？
多谢！
注意：已经过去很长时间了，但我认为这个问题与分布式事务协调器有关。 我摆弄了它很长时间，但始终无法让它工作。
When TransactionScope first came out, I ran into some serious issues getting it to work between my dev machine (XP) and our database server (Windows Server 2003).
When I looked into it more, this appeared to be a tricky and widespread issue that had a chance of becoming a headache in production, so I decided not to handle transactions this way (even though I like the syntax a lot and I really wanted it to work).
Are these problems still out there or is this safe to use? Do you use this regularly now without issues?
Thanks a lot!
Note: It has been a long time now, but I think the issue had something to do with Distribute Transaction Coordinator. I fiddled with it for a long time and was never able to get it working.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Rick Strahl 在此处发表了一篇关于事务范围和 LINQ to SQL 的精彩文章。 它的上下文更多的是 LINQ to SQL，但我认为有一些适用的原则可以帮助您解决问题。
编辑：为了更具体地回答你的问题，以下是斯特拉尔对 TransactionScope 的看法：
Rick Strahl has a great post about transaction scope and LINQ to SQL here. Its context is more LINQ to SQL, but I think that there are some principles that apply which could help you solve your question.
EDIT: to more specifically answer your question, here's what Strahl has to say about TransactionScope:
我已经使用 TransactionScope 一年多了，没有任何问题。 然而，该应用程序是一个内部应用程序，用户数量很少。 此外，数据库和应用程序驻留在同一服务器上。
以下是有关 TransactionScope 的一些信息以及在何处查找更多信息：
每当您创建 TransactionScope 对象时，它都会启动一个轻量级事务。 那么只要您使用支持轻量级事务的单个连接/资源，事务就会由资源管理器处理，消耗尽可能少的资源，并且性能非常好。 当您将第二个连接/资源添加到事务范围时，事务管理器将自动升级为 OleTx 事务管理器，它可以使用 COM+ DTC 技术处理分布式事务。 如果与不支持轻量级事务的资源管理器（例如 SQL Server 7/2000、Oracle 和其他 RDBMS）进行单一连接，也会发生这种情况。
以下两个资源可能会对您有所帮助：
“Microsoft Windows Server 2003 Service Pack 1 (SP1) 和 Microsoft Windows XP Service Pack 2 (SP2) 包括许多与安全相关的更新和更改。其中一些更改会影响 Microsoft分布式事务协调器 (MSDTC) 服务。”
Windows Server 2003 Service Pack 1 和 Windows XP Service Pack 2 中分布式事务协调器服务的新功能< /a>
和
Juval Lowy 关于 System.Transactions 的白皮书：
在Microsoft .NET Framework 2.0 版
I have been using TransactionScope for over a year now without any issues. However, the application is an internal application with a very small number of users. Also, the database and application reside on the same server.
Here is some information on TransactionScope and where to look for more information:
Whenever you create a TransactionScope object it starts a lightweight transaction. Then as long as you use a single connection/resource that supports lightweight transactions, the transaction will be handled by the resource manager consuming as little resources as possible with very good performance. When you add a second connection/resource into the transaction scope the transaction manager will automatically be promoted to an OleTx Transaction Manager, which can handle distributed transactions by using the COM+ DTC technologies. This will also happen with a single connection to a resource manager that doesn't support lightweight transactions such as SQL Server 7/2000, Oracle and other RDBMSs.
Here are two resources that may be able to help you out:
"Microsoft Windows Server 2003 Service Pack 1 (SP1) and Microsoft Windows XP Service Pack 2 (SP2) include many security-related updates and changes. Some of these changes affect the Microsoft Distributed Transaction Coordinator (MSDTC) service."
New functionality in the Distributed Transaction Coordinator service in Windows Server 2003 Service Pack 1 and in Windows XP Service Pack 2
and
Juval Lowy's whitepaper on System.Transactions:
Introducing System.Transactions in the Microsoft .NET Framework version 2.0
关于 TransactionScope 仍然存在问题。 在我当前的项目中，我们不定期地遇到“无法加入分布式事务”异常和 TransactionInDoubtException。 这两个异常都与 TransactionScope 相关。 针对这两个异常的一种解决方法是使用单个 oracle 连接（当然如果适用）。
请阅读以下内容：避免不必要的升级到分布式事务
有关性能影响的信息，请阅读我的文章：使用 TransactionScope 的性能影响
There are still issues regarding TransactionScope. In my current project we are at irregular intervals running into both “Unable to enlist in a distributed transaction” exceptions and TransactionInDoubtException. Both exceptions related to TransactionScope. One workaround for both exceptions is to use a single oracle connection (if applicable of course).
Read about this in: Avoid unwanted Escalation to Distributed Transactions
For information on performance impact please read my post: Performance impact using TransactionScope