一夜不活动后的一般网络错误

Question

一段时间以来,我们的旗舰应用程序一直存在神秘错误.错误消息是通用的

[DBNETLIB] [ConnectionWrite(send()).]常规网络错误.检查您的网络文档.

这可以通过让应用程序在晚上开放并在早上恢复工作来可靠地再现.由于它是后端服务器应用程序,这是正常情况.

有趣的是 - 我们已经从SQL Server 7迁移到2000年到2008年,所有这些问题都存在.但似乎重要的是我们运行应用程序的操作系统.在WinXP上运行正常,在Vista/7上它失败了.所以问题出在客户端.

谷歌在错误消息上的结果涵盖了非常广泛的不同原因(因为这是一个非常普遍的错误),并且没有找到与我们类似的情景.

所以也许周围的人会知道我们的问题是什么？

Answer 1

您应该能够通过以下方式重现此错误情况:
1.打开数据库连接(在客户端应用程序中)
2.拔下网络电缆
3.重新插入网络电缆(等待网络连接恢复)
4.使用先前打开的连接查询数据库

据我所知,客户端ADO代码无法一致地确定底层网络连接是否实际有效.检查数据库连接是否已打开(在客户端代码中)返回true.但是,对该连接执行任何操作会导致a General network error.

连接池似乎能够确定连接何时变为"坏",因此它永远不会返回与应用程序的错误连接.它只是打开一个新的连接.

因此,如果应用程序长时间保持数据库连接(已使用或未使用),则底层TCP/IP连接可能会中断.

底线是应该关闭数据库连接并在不使用时返回到连接池.

编辑

此外,根据连接到数据库的客户端数量,不使用连接池可能会导致另一个问题.您可以达到服务器端打开的最大套接字数.这是来自记忆.在客户端关闭连接后,服务器上的连接将进入TIME_WAIT状态.默认情况下,服务器套接字大约需要4分钟才能关闭,因此在此期间其他客户端无法使用它.最重要的是,服务器上的可用套接字数量有限.保持太多连接打开可能会产生问题.

我工作的一个项目很容易达到这个套接字限制,大约有120个用户.添加了一个新的"功能",绝对会破坏服务器,在使用该应用程序几个小时后,每个人都会突然停下来.SQL服务器没有及时关闭足够的套接字以用于新的连接请求.尽管共有65K个套接字,但只有前5000个可用于ADO(这是默认的注册表设置,因此可以更改).

TIME_WAIT状态下的套接字数量会逐渐增加,直到操作系统不再分配为止.因此,客户端必须等到服务器端套接字关闭,然后才能创建新连接.