C#学习教程：在执行长时间运行的数据库任务时处理Web服务超时从网络服务。Web服务访问数据库以获取信息并将其返回给客户端。这就是问题。其中一些查询可能需要很长时间，我们不知道哪些会很慢。我们知道有些通常比其他的慢，但即使是最简单的请求，只要有足够的数据，也可能很慢。有时对大量数据使用查询或运行报告。只能优化查询，直到大量数据减慢它们的速度。如果数据库中的查询达到SQLServer中的最大查询超时，数据库查询将终止，Web服务将错误返回给客户端。这是可以理解的。我们可以处理这些错误。客户端正在等待Web服务调用完成。如果数据库调用耗时较长，可能是客户端调用web服务时超时。客户端放弃，但数据库请求继续处理。此时，客户端与数据库不同步。数据库调用可能成功也可能不成功。可能有错误。客户永远不会知道。在某些情况下，我们不希望我们的用户发起另一个请求，如果先前的请求已完成，这可能会导致无效状态。我很想看看其他人是如何处理这个问题的。您使用了哪些策略来防止Web服务超时影响数据库调用？我能想到的最好的想法是在某处创建一个实际的数据库层——在Web服务内部，附加到消息队列——某处。将每个查询卸载到另一个进程似乎过多。（那么，我们并不总是知道给定的请求是快还是慢。）如果我们能够将发出HTTP请求的行为与启动和运行数据库进程的行为分开，那就太好了。我在以前的公司看到过自定义服务器的使用，但它使用的是直接套接字通信，我宁愿避免用某些自定义应用程序替换Web服务。请注意，鉴于我们正在处理的数据量，我们都在进行查询优化。如果数据量很大，查询优化、索引等只能让你走到这一步。有时事情需要很长时间。我之前遇到过类似的问题，并使用以下3种方法之一解决了它：将所有长时间运行的查询添加到队列中并按顺序处理它们。在我的例子中，这些是复杂的报告，然后通过电子邮件发送给客户或存储在一个永久的“临时”表中，供客户在收到通知后查看。我们使用JQuery调用调用Web服务，然后在完成时调用javascript回发方法。当我们不希望页面加载与Web服务正在执行的操作同步时，这很有效。但是，这确实意味着该功能在长时间运行的进程完成之前不可用。最复杂的一个。我们弹出另一个显示进度条的窗口，它也会定期轮询服务器。这使用会话变量来确定显示进度条的距离。启动进度条后，将启动一个新线程，该线程会定期更新同一会话变量。一旦会话变量值设置为100，弹出窗口将自行关闭。客户喜欢这种方法。无论如何，我希望其中之一对您有所帮助。Web服务可以在线程池中运行查询，如果线程没有完成，比如说5秒（参见Thread.Join()），Web服务调用返回客户端JobID而不是客户端可以使用的结果集每隔几秒轮询服务器以查看其查询是否已完成。当线程结束时，结果可以存储在哈希表中，直到客户端再次轮询。我们最近使用的解决方案之一是将大型数据库进程分解为单独的并行操作。每个操作都小得多，并且设计得尽可能高效。客户端启动一个操作，生成多个线程，并可以并行执行任何操作。例如，我们将一些重要的流程拆分为“开始”、“流程1工作块”、“完成”和“收集报告数据”等一系列步骤。流程工作步骤可以并行运行，但只有在“开始”步骤完成后才能开始。Completionsteps需要等待所有ProcessWork步骤完成。由于客户端在控制流程，因此客户端可以报告其确切步骤的进度。将问题分解成更小的部分绝对是个好主意。除此之外以及其他人所说的（并且只有在您帮助实施网络服务的情况下）我一直在使用传递给网络服务的回调网址。WS必须在错误的情况下调用它才能生成查询字符串或发布数据。URL通常包含一个令牌，用于允许回调重新进入客户端，并映射到收到回调后执行操作所需的任何相关信息（存储在数据库或内存中）。它有点重（特别是如果你没有在网络服务器上运行）但是在客户端超时的情况下保证成功的往返但是网络服务正确接收指令并且处理速度很慢。设置完成后，您的Web服务实际上更接近于准备好异步运行并因此快速回复客户端：通常，如果可以的话，进行任何检查以回答，并在单独的循环中生成缓慢的操作，回调url，以便它可以向客户端报告。我不确定这是多么正统，顺便说一句，但它确实解决了一个真正的问题。以上是C#学习教程：HandlingWebservicetimeoutsharingwhenexecutinglong-runningdatabasetasks。如果对大家有用，需要了解更多C#学习教程，希望大家多加关注——本文来自网络合集，不代表立场，如涉及侵权，请点击右边联系管理员删除。如需转载请注明出处：
