2

我有一个托管在 IIS 中的 WCF Web 服务——该服务有一个方法——我们称之为 DoSomething()。DoSomething() 从客户端应用程序调用。

DoSomething 执行一些工作并将答案返回给用户。现在我需要记录 DoSomething 被调用的频率。我可以将它添加到 DoSomething 函数中，以便每次调用都会写入 sql 数据库并更新计数器，但这会减慢 DoSomething 方法的速度，因为用户需要等待这个额外的数据库调用。

让 DoSomething 方法生成一个新线程来更新数据库中的计数器，然后将 DoSomething 方法的答案返回给用户而不等待线程完成，这是一个不错的选择吗？然后我将不知道数据库更新是否失败，但这并不重要。

产生一个新的后台线程而不是等待它在 WCF 中完成有什么问题吗？或者有没有更好的方法来解决这个问题？

更新：以不同的方式提出问题。在 wcf Web 服务方法中生成新线程是不是一个坏主意？

4

2 回答 2

2

主要问题之一是可靠性。这是你关心的电话吗？如果 IIS 进程在您返回响应后崩溃，但在您的线程完成之前，这有关系吗？如果不是，那么您可以使用客户端 C# 工具。如果它确实重要，那么您必须使用可靠的排队技术。

如果您使用客户端，那么生成一个新线程只是为了阻止数据库调用永远不是正确的答案。您想要的是使调用异步，并为此在确保在连接上启用之后使用SqlCommand.BeginExecute 。AsyncronousProcessing

如果您需要可靠的处理，那么您可以使用依赖于持久队列的异步过程执行等模式。

附带说明一下，如果在每个 HTTP 请求上写入数据库的幼稚方法完成，诸如日志记录或命中计数之类的事情将是一个巨大的性能瓶颈。您必须批处理和冲洗。

于 2012-06-22T11:09:32.050 回答
1

如果您只想跟踪DoSomething()服务中的单个方法，则可以创建自定义操作行为并将其应用于该方法。

操作行为将包含将信息记录到数据库的代码。在该操作行为中，您可以使用 .NET 4.0 的新 TPL 库来创建一个负责数据库日志记录的任务。如果您使用 TPL，则无需担心直接创建线程。

明天使用操作行为的优点是您需要跟踪另一个方法，然后在那个时候而不是在那里复制代码，您只需使用自定义操作行为标记该方法。如果你想跟踪所有的方法，那么你应该去寻找服务行为。

要了解有关操作行为的更多信息，请查看http://msdn.microsoft.com/en-us/library/system.servicemodel.operationbehaviorattribute.aspx

要了解有关 TPL（任务并行库）的更多信息，请查看http://msdn.microsoft.com/en-us/library/dd460717.aspx

于 2012-06-19T09:29:44.070 回答