WCF 服务中数据的保证处理
我有一个 WCF 服务，可以处理来自 SAP 的数万条记录的源。该服务调用采用 XElement 作为其主要参数，并处理 XML 以更新数据库中的记录。当前的目的是异步调用 WCF 服务，并使服务调用将包含已处理的每条记录的状态的同一文档发送回调用者。
我也在研究多线程数据处理的方法，尽管这最终可能不会给我带来任何好处。
因为这可能需要一段时间，所以我担心如果 WCF 服务终止、重新启动等会发生什么。我需要知道我已经处理了哪些记录，还没有处理哪些记录，并且能够完成处理关于剩余的记录。
我能想到的最好办法是更新每个节点的状态（无论如何，我必须这样做，以发送回调用者），并将该文件保存到硬盘驱动器。但保存这么大的文件（可能保存 100,000 次）似乎不太可行。
在处理这些记录时，我还可以使用哪些其他策略来跟踪这些记录？
蒂亚！
詹姆斯
I have a WCF service that processes a feed of tens of thousands of records from SAP. The service call takes an XElement as its main parameter and processes the XML to update records in our database. The current intent is to have the WCF service be called asynchronously, and to have the service call send back to the caller the same document with statuses for each record processed.
I'm also looking into ways to multithread the processing of the data, though this may not end up buying me anything.
Because this could take a while, I'm concerned about what will happen if the WCF services dies, gets restarted, etc. I need to know which records I've processed, and which I haven't, and be able to complete processing on the remaining records.
The best I've been able to come up with is to update each node with a status (I have to do this, anyway, to send back to the caller), and save this file to the hard drive. But saving a file that large potentially 100,000 times doesn't really seem feasible.
What other strategies could I use to track these records as I process them?
TIA!
James
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为使用 MSMQ 是满足您概述的大部分需求的好方法。如果您将节点分解为消息并将它们输入事务队列中。
通过拥有更多会更容易
机器在队列一上处理
你已经发挥了最大的能力
一。
MSMQ WCF 操作方法链接：
http://msdn.microsoft.com/en -us/library/ms789048.aspx
http://code.msdn.microsoft.com/msmqpluswcf
I see using a MSMQ as being a great way to fulfill most of the needs you outlined about. If you broke the nodes into messages and entered them in a transactional queue.
would be easier through having more
machines processing on the queue one
you maxed out the capabilities of
one.
Links to MSMQ WCF how-to's:
http://msdn.microsoft.com/en-us/library/ms789048.aspx
http://code.msdn.microsoft.com/msmqpluswcf
也许您可以首先将记录（来自 XML）放入数据库中，也许放在一个特殊的“要处理的记录”表中。每行还可以用某种方式标记，以将它们与特定请求相关联。处理数据库中的行。在处理每一个时，更新状态字段（对应于您在 XmlElement 上更新的节点状态）。完成后，您可以返回并更新 XML（如果您在此期间没有崩溃），也可以生成新的 XML（如果您无法往返转换 XML->database-，则可能会出现问题） > XML。
如果服务终止，检查数据库以查找尚未处理的记录并完成处理它们应该相对简单，
或者可以将 XML 文件写入磁盘一次，在数据库中保留一个表。仅保存“状态”字段（以及一个或多个键，以便您再次在 XML 文件中找到相应的记录），处理记录，更新数据库“状态”表。完成后，更新状态字段。通过从“状态”表中读取状态来一次性写入 XML 文件。
同样，如果服务终止，检查“状态”表以查看哪些行已被处理、哪些行尚未处理应该足够简单。
祝你好运！
Maybe you could put the records (from your XML) in your database first, maybe in a special "records to be processed" table. Each row might also be tagged with some way to correlate them with a specific request. Process the rows from the database. As you process each one, update the status field (corresponding to the node status that you would have updated on the XmlElement). When you are finished, you could either go back and update the XML (if you haven't crashed in the meantime) or you could generate new XML (could be problematic if you can't round trip the conversion XML->database->XML.
If the service dies, it should be relatively simple to examine the database to find the records that have not been processed and finish processing them.
Alternatively, could write the XML file to disk once, keep a table in the database that holds ONLY the "status" field (and one or more keys to allow you to find the corresponding record in the XML file again), process the records, update the database "status" table as you go. When finished, update the status fields in the XML file in one fell swoop by reading the status from the "status" table.
Again, if the service dies, it should be simple enough to examine the "status" table to see which rows have been processed and which have not.
Good luck!
如果您的源数据库和目标数据库都是 SQL Server，那么您应该忘记中间人，直接使用数据库中的内置队列支持：服务代理。与 MSMQ 相比，您可以获得许多优势：
还有其他优点：
您丢失的一件事是 WCF 服务模型编程。 WCF 确实使编写演示应用程序变得非常容易，您将失去它。
If your source and destination databases are SQL Server, then you should forget about middle-men and go straight to the built-in queuing support in the database: Service Broker. You get a number of advantages over MSMQ:
There are other advantages too:
The one thing you loose is the WCF service model programming. WCF makes it indeed extremely easy to write demo apps and you'll loose that.
您是否考虑过消息传递服务器，例如 Microsoft 消息队列。
Have you considered a messaging server, such as Microsoft Message Queuing.