基本架构：n 个物理盒子，每一个都承载相同的 WCF 服务，开始放置一个负载均衡器。每个盒子都击中一个不支持事务的数据库基础设施 - 不要问:(
因此，在我的应用程序的数据访问层中，我需要一些分布式事务的方法。我有哪些选择？
请注意，我系统的客户端将是使用基本 Web 服务（BasicHttpBinding）和闪亮的新 WCF 客户端（NetTcpBinding 或 NetNamedPipeBinding）进行通信的旧应用程序。
编辑 1
例如，将在物理框 1 上对 WCF 层进行一次调用，例如 EditEntity(...)。此调用将触发对数据库的 2 次写入。在第一次写入之后，另一个客户端调用 EditEntity(...) 为第二个物理框上我的 WCF 服务的第二个实例上的同一实体。在第二个框中，我如何知道该特定实体的交易已经在进行中？
谢谢。
不确定您是否已经为我们提供了足够的支持，但如果我没看错，您是在尝试确保您可以通过 WCF 服务支持事务吗？虽然您的数据库不支持事务，并且您的 WCF 端点位于负载均衡器后面？我有这个正确的吗？如果是这样的话....
由于您的数据库没有事务支持，因此将转移到您的 WCF 层。这表明您的方法中有一个粗略的粒度级别，以便您可以确保对 WCF 服务的单个调用足以包含您的事务。不要将事务分散到多个 WCF 调用中，这是在自找麻烦。
更新：负载均衡器可以使用一些策略来确保连接之间的持久性，但这对您没有帮助。如果您连续调用 EditEntity()，并且第一个条目是启动事务，第二个条目是完成事务......那么您的服务不够精细。
将这两个调用合并到一个方法，即EditEntityComplete()。
您是否有理由不能创建一种方法，而不是两种？
更新 #2：重新表述问题 - 单个方法在不支持事务的数据库中执行条目。所讨论的方法执行一系列必须按顺序完成的步骤。WCF 方法表示并发争用违反正确顺序的步骤完成的机会。
在此基础上，假设您不需要函数的任何返回数据，请考虑使用可以记录来自 WCF 端点的请求的异步队列。然后从单个后台进程处理队列。
最终修订：
重新考虑不更改数据存储的要求。
考虑到对多个客户端的要求，数据存储中需要扩展、负载平衡和事务支持，最后的建议是——推动更改数据库。理解这是一个静态需求，但是当大量简单的数据库平台为您提供事务支持时，您将花费大量精力来尝试实现事务支持。尝试重新创建此功能几乎没有好处，但有很多缺点。