是什么原因导致＆QUOT;内部连接致命错误＆QUOT; [英] What Causes "Internal connection fatal errors"

问题描述

我已经得到了一些ASP.Net网站（.NET v3.5版本）与SQL 2000数据库后端的服务器上运行。几个月来，我一直收到看似随意InvalidOperationExceptions消息内部连接致命错误。有时候，有一个在中间的几天，而其他时候每天有多个错误。

I've got a number of ASP.Net websites (.Net v3.5) running on a server with a SQL 2000 database backend. For several months, I've been receiving seemingly random InvalidOperationExceptions with the message "Internal connection fatal error". Sometimes there's a few days in between, while other times there are multiple errors per day.

的异常不限于在特定的一个部位，尽管它们共享业务和数据访问组件。该错误似乎始终从SqlClient.TdsParser.Run抛出（）。有时是从老派的直接SqlCommand.Execute（）调用抛出，而其他时候它是从LINQ2SQL code抛出。

The exception is not limited to one site in particular, though they share business and data access assemblies. The error seems to always be thrown from SqlClient.TdsParser.Run(). It sometimes is thrown from old-school direct SqlCommand.Execute() calls, while other times it is thrown from Linq2Sql code.

我已经放心的网络人员，有没有失去他们的最终错误或数据包。任何人都经历吗？难道是一个驱动程序问题？我们已经无法作为尚未查明该异常的特定的触发。

I've been assured by the network guys that there are no errors or packets lost on their end. Has anyone else experienced this? Could it be a driver problem? We have been unable as of yet to pinpoint a specific trigger for this exception.

我们正在Windows Server 2003上运行II6。

We're running II6 on Windows Server 2003.

推荐答案

忽略这个问题几个月后，它开始达到一个临界质量交通逐渐增加。在重负载，包括一些爬虫，事情变得疯狂，这些错误在不停浇。

After a few months of ignoring this issue, it started to reach a critical mass as traffic gradually increased. Under heavy load, including some crawlers, things got crazy and these errors poured in nonstop.

经过反复试验，我们终于找到了的SqlCommand或LINQ查询它的SqlConnection不使用后立即关闭了一把。相反，通过一些草率编程从LINQ连接的误解始发，在DataContext物体设置（和连接闭合）仅在一个请求而不是立即的端

Through trial and error, we eventually tracked down a handful of SqlCommand or LINQ queries whose SqlConnection wasn't closed immediately after use. Instead, through some sloppy programming originating from a misunderstanding of LINQ connections, the DataContext objects were disposed (and connections closed) only at the end of a request rather than immediately.

一旦我们重构这些方法立即关闭与C＃使用块（释放该池下一个请求）的连接，我们并没有收到更多的错误。虽然我们仍然不知道的根本原因，一个连接池会变得这么混在一起，我们能够停止这种类型的所有错误。这个问题在与其他类似的错误，我张贴一起得到了解决，在这里找到：<一href=\"http://stackoverflow.com/questions/882784/why-is-my-sqlcommand-returning-a-string-when-it-should-be-an-int\">Why是我的SqlCommand返回一个字符串时，它应该是一个int？

Once we refactored these methods to immediately close the connection with a C# "using" block (freeing up that pool for the next request), we received no more errors. While we still don't know the underlying reason that a connection pool would get so mixed up, we were able to cease all errors of this type. This problem was resolved in conjunction with another similar error I posted, found here: Why is my SqlCommand returning a string when it should be an int?

这篇关于是什么原因导致＆QUOT;内部连接致命错误＆QUOT;的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！