在 Web 服务中处理静态资源答案

【问题标题】：Disposing of static resources in web service在 Web 服务中处理静态资源
【发布时间】：2011-03-29 14:06:39
【问题描述】：

在 WCF 之前的 .NET (C#) Web 服务中，我有一个昂贵的 IDisposable 资源，我持有一个静态（实际上是 ThreadStatic）引用。（在内部它包含一个 SqlConnection。）如何确保在应用程序池刷新时处理它，我应该简单地抑制 FxCop 警告而不担心它，还是有第三种选择？

最初该服务使用 using 块打开每个请求的连接，但该设计因“连接资源问题”而被拒绝。

【问题讨论】：

标签： c# web-services static dispose sqlconnection

【解决方案1】：

由于连接资源问题，此设计将被拒绝。如果您之前遇到问题，您将再次遇到问题，因为您现在将使用更多的 SqlServer 连接（如果它是线程静态的，那么每个线程将有一个 SqlServer 并且 - 更重要的是 - 一个底层真实连接，即使它没有使用并且会返回到池的底层连接）。

【讨论】：

非常好。我没有选择新的设计。你有什么建议？
您需要重新检查您的连接资源问题，看看实际问题是什么。通常，最好的模式是打开一个连接，执行操作，然后关闭它，或者通过连接上的 using 块，或者 - 如果您要返回一个 datareader 以便可以有效地迭代它，一个 datareader 在 using使用 CloseConnection 选项创建的块，因此它的处置触发器是连接的处置。这样，“真实”连接就会尽快返回到池中。您在此处的更改因永不退回而使事情变得更糟。通常的模式哪里出错了？...
...在为数据读取器创建连接（因此不在使用中）和将数据读取器放入使用之间是否发生了错误？这种情况可能会导致泄漏（我为此使用了一个包装器类，它将在其处置时处置连接，但是当它成功创建具有关闭选项的数据读取器时，将“停止拥有”该连接，因为它现在是读取器关闭它。另一个错误来源是，如果您在 interator 块中的 datareader 上执行 using，并且无论是作为错误还是故意，永远不要进入 using 块，因为第一个 ...
...迭代不会发生。同样，一个解决方案是一个包装器类，在这种情况下，一个可枚举的包装器“窥视”第一项，以便始终输入阅读器使用代码中的 using 块。其他原因当然是可能的，以上只是我在实际代码中看到的原因。我确信的一件事是，使用太多同时连接的解决方案不是更改为使用更多连接的设计。
...你是对的，@Jon。我们没有解决这个问题，当我们达到最大池大小（100）时，问题就出现了。谢谢！