wcf 分布式事务的事务协调器 [英] Transaction coordinator for wcf distributed transactions

问题描述

我知道事务协调器用于协调不同类型资源之间的事务，例如 1)SQL Server 2)Oracle 3)MSMQ 4)文件系统等，他们有责任跟踪事务以及任何这些资源失败都应该回滚 WCF 中所有其他资源的事务.

I know that Transaction coordinators are used for coordinating transaction between different types of resources such as 1)SQL Server 2)Oracle 3)MSMQ 4)File System etc. and it is their responsibility to keep tracks of transactions and if transaction of any of this resources failed it should rollback transaction of all other resources in WCF.

我想知道a) 选择哪个事务协调器以及为什么b) 我们可以自己选择事务协调器还是由 wcf 自己自动完成对于以下条件:-

I would like to know a) Which transaction coordinator to choose and why b) Can we choose transaction coordinator by itself or it will be done automatically by wcf itself for following conditions :-

1)如果 wcf 使用相同 Microsoft 技术的事务(Microsoft SQL Server & Microsoft Message Queue)

1)If wcf uses transactions for same Microsoft technology(Microsoft SQL Server & Microsoft Message Queue)

2)如果 wcf 使用事务处理不同的数据库技术(Microsoft SQL Server、Oracle 和 MySQL)

2)If wcf uses transaction for different database technology(Microsoft SQL Server, Oracle and MySQL)

3)如果 wcf 对所有不同类型的资源使用不同的技术(Microsoft SQL Server、Oracle、文件系统等)使用事务

3)If wcf uses transaction for all different types of resources with different technlogies(Microsoft SQL Server, Oracle, File System etc.)

推荐答案

我强烈建议不要在这种异构环境中使用 DTC.涉及多种风险.只有其中一个限制了您未来的选择:如果您必须使用无法将其纳入事务的文件系统(例如网络文件共享)怎么办?还是云前端?或者一些第三方服务?

I would strongly advice against using DTC in such a heterogeneous environment. There are multiple risks involved. Only one of them is limiting your future choices: what if you have to use a file system that cannot enlist it a transaction (say, network fileshare)? Or cloud frontend? Or some 3rd party service?

此外，DTC 将您系统的各个部分非常糟糕地耦合在一起.涉及各种耦合:空间、时间甚至平台(因为每个人必须知道如何加入特定的 DTC).

Also DTC couples parts of your system together very badly. All sorts of coupling are involved: spatial, temporal, even platform (because everyone must know how to enlist in a specific DTC).

尽管在性能(使用 DTC 时比不使用 DTC 时差 数千 倍)方面，DTC 仍能很好地工作，直到它没有为止.如果您使用 DTC，您应该准备好应对交易有疑问"的情况和各种故障排除.它应该是您设计的一部分.

Despite performance (which is thousands of times worst with DTC than without) aspects, DTC works great until it doesn't. You should be prepared to "transaction is in doubt" situations and all sorts of troubleshooting if you use DTC. And it should be a part of your design.

在某些情况下，系统中对于一些罕见的特定情况需要 DTC，但是如果您发现自己处于一种情况，当您将交易和 DTC 视为一把神圣的金锤(我们刚刚开始交易，如果出现问题，我们只是"回滚所有内容)我建议您立即停止.如果您停在这里，您将节省大量时间、错误、神经、金钱和资源.

There are cases when DTC is needed for some rare specific cases in systems, but if you find yourself in a situation when you look at transactions and DTC as at a holy golden hammer (we just start transaction, and if something fails we "just" rollback everything) I recommend you to stop right now. You will save tons of time, bugs, nerves, money, resources if you stop here.

我相信做出不需要 DTC 的适当设计会更合乎逻辑，也更好.记住:业务不会回滚.我们这样做，程序员.当资金从一个账户转移到另一个账户时(可能在不同的银行)，不涉及 DTC，这会很疯狂.他们不回滚，他们补偿.有一些模式和方法可以正确地做到这一点，我们不能只是将整个世界包装在一个事务中.

I believe it would be more logical and much better to make a proper design that would not require DTC. Remember: business does not rollback. We do, programmers. When money are being transferred from one account to another (possible in different banks), there is no DTC involved, it would be crazy. They do not rollback, they compensate. There are patterns and ways to do it properly, we cannot just wrap the whole world in a transaction.

因此，针对可以自主运行并自然地相互通信的独立上下文设计您的系统，您会发现自己处于一个更美好的世界:)

So design your systems against independent contexts that can operate autonomously and communicate to each other naturally and you will find yourself in a much better world :)

这篇关于wcf 分布式事务的事务协调器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！