使用 WCF 进行分布式事务
基本架构：n 个物理盒子，每个盒子托管相同的 WCF 服务，并启动一个负载均衡器。 每个盒子都击中一个不支持事务的数据库基础设施 - 不要问:(
因此，在我的应用程序的数据访问层中，我需要某种分布式事务方法。我的选择是什么？
注意我的系统的客户端将是使用基本 Web 服务 (BasicHttpBinding) 和闪亮的新 WCF 客户端（NetTcpBinding 或 NetNamedPipeBinding ）进行通信的旧应用程序
编辑 1
例如，将在物理上对 WCF 层进行一次调用 。框 1，例如 EditEntity(...)。在第一次写入后，另一个客户端在第二个物理上的 WCF 服务的第二个实例上调用 EditEntity(...)。在第二个框中，我如何知道该特定实体的交易已经在进行中
？
Basic architecture: n physical boxes each hosting the same WCF service, sitting begind a load balancer. Each box hitting a single database infrastructure that does not support transactions - don't ask :(
So, in the data access layer of my app I need some method of distributed transactions. What are my options?
Note that clients to my system will be legacy apps communicating using basic web services (BasicHttpBinding) and shiny new WCF clients (NetTcpBinding or NetNamedPipeBinding ).
Edit 1
E.g. there will be a single call into the WCF layer on physical box 1, e.g. EditEntity(...). This call will trigger 2 writes to the database. After the first write another client calls EditEntity(...) for the same entity on a second instance of my WCF service on a second physical box. On the second box how do I know that a transaction for this particular entity is already in play?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不确定您是否给了我们足够的支持，但如果我没理解错的话，您是在尝试确保可以通过 WCF 服务支持事务吗？ 虽然您的数据库不支持事务，并且您的 WCF 端点位于负载均衡器后面？ 我这个正确吗？ 如果是这样......
由于您的数据库没有事务支持，因此会转移到您的 WCF 层。 这表明您的方法具有粗粒度级别，以便您可以确保对 WCF 服务的单次调用充分包含您的事务。 不要将事务分散到多个 WCF 调用中，否则会带来麻烦。
更新：有一些策略可以与负载均衡器一起使用，以确保连接之间的持久性，但这对您没有帮助。 如果您连续调用 EditEntity()，并且第一个条目是发起事务，第二个条目是完成事务......那么您的服务不够精细。
将这两个调用合并到一个方法，即 EditEntityComplete()。
是否有原因导致您无法创建一个方法而不是两个方法？
更新 #2：重新表述问题 - 单一方法在不支持事务的数据库中执行条目。 该方法执行一系列必须按顺序完成的步骤。 WCF 方法代表并发争用违反步骤完成顺序的机会。
在此基础上，假设您不需要函数返回任何数据，请考虑使用可以记录来自 WCF 端点的请求的异步队列。 然后从单个后台进程处理队列。
最终修订：
重新考虑不更改数据存储的要求。
考虑到对多个客户端的要求、数据存储中对规模、负载平衡和事务支持的需求，最后的建议 - 推动更改数据库。 了解这是一个静态要求，但是当大量简单的数据库平台可以为您提供事务支持时，您将花费大量精力来尝试实现事务支持。 尝试重新创建此功能几乎没有什么好处，但有很多缺点。
Not sure you've given us enough to go on, but if I'm reading correctly you're attempting to make sure you can support a transaction through your WCF service? While your DB doesn't support transactions, and your WCF endpoints sit behind a load balancer? Do I have this correct? If so....
Since your DB doesn't have transactional support, that moves to your WCF tier. This suggests a coarse level of granularity in your methods such that you can ensure a single call to your WCF service encompasses your transaction sufficiently. Don't spread a transaction across multiple WCF calls, you're asking for trouble.
UPDATE: There are strategies that can be employed with load balancers that ensure persistence among connections, but that won't help you here. If you're calling EditEntity() consecutively, and the first entry is to initiate a transaction, and the second entry is to complete a transaction...then your service is not granular enough.
Consolidate those two calls to one method, i.e. EditEntityComplete().
Is there a reason that you cannot create one method, as opposed to two?
UPDATE #2: Rephrasing the issue - a single method performs entries within a database that does not support transactions. The method in question executes a series of steps that must be completed in order. The WCF method represents opportunities for concurrency contention to violate step completion in the proper order.
With that basis, assuming you don't require any return data from the function, consider an asynchronous Queue that can log requests from the WCF endpoints. Then process the Queue from a single background process.
FINAL REVISION:
Reconsider the requirement of not changing the data store.
Given the requirements for multiple clients, need for scale, load balancing and transactional support in the data store, a final suggestion -- push to change the database. Understanding this is a static requirement, but you will expend a lot of effort trying to implement transactional support when plenty of simple database platforms will provide it for you. Trying to re-create this functionality has little upside but a lot of downside.