这个问题分为两部分。
我在IIS 6中托管了单向WCF操作。以下是我对其工作原理的理解：
_1。 IIS收到请求。
_2。 IIS发送HTTP 202响应（谢谢，稍后我将对此进行处理）。
_3。 IIS调用我的单向WCF操作。
现在控制传递给我的WCF操作，该操作执行以下操作：
_4。将请求信息保留在事务性的持久存储中。
_5。开始在OLTP数据库中处理请求。
_6。如果出现错误，请从步骤5开始重复，或采取一些补救措施，然后清除步骤4中持久存储的数据。
我对IIS何时发送HTTP 202响应的理解是否正确？
如果IIS在步骤2和步骤4之间循环使用，我可能会在我进行更改之前丢失请求信息，但在客户认为我已接受该消息之后。 IIS是否有任何保证在有待处理的请求时何时会或不会回收？
PS：请原谅狡猾的格式。由于某种原因，降价完全搞砸了我的编号清单项目。
答案 0 :(得分：1)
我不确定你的假设是否正确。
即使对于单向交互，WCF也可以在返回202之前进行非常的调整;例如，如果您使用身份验证，则必须在调用方法之前和返回202之前进行，以便在出现任何问题时可以报告。
如果您使用wsHttpBinding，例如，开箱即用，您将看到2-3个消息交换，在实际方法调用之前产生200。这是为了交换安全信息和建立安全背景。
不可否认，如果您将服务配置为没有安全性，则不会发生这种情况，它将立即返回202，但这表明它必须知道它是否可以从WCF堆栈中执行此操作。
除此之外 - 我不确定您要实现的目标 - 您指的是哪些IIS回收？我不是IIS的专家，但我怀疑它会在主动执行时回收主机;如果你是指任何人手动重新申请应用程序池（或IIS或机器），我怀疑你能做多少。
如果您必须确定消息没有丢失，我知道保证的唯一方法就是以某种方式使用可靠的消息传递，这只会在持久存储中确认请求;
答案 1 :(得分：0)
在我看来，我会提出一些建议：
我知道在IIS中管理进程回收的唯一方法是查看您的网站正在使用的应用程序池。如果您打开IIS管理器 - ＆gt;应用程序池 - ＆gt;选择您的池然后右键单击属性，在回收选项卡上有可能对您有帮助的选项。我想这并不能保证你不会在循环中丢失请求，而是设置更长的时间来减少这种情况的可能性。
然而，听起来你正在构建的那种系统是MSMQ的理想候选者，MSMQ可以提供异步服务请求，这些请求排队正确，只需很少的开销或手动管道。这样可以完全避免整个过程回收问题。我不确定这是否适用于您的场景，但可能需要考虑一下。