2013-10-30 195 views
0

当NHibernate的日志级别设置为“DEBUG”时,我们开始在日志中看到一堆“内部连接致命”错误。它看起来像NHibernate通过处理一个特定的结果集而夭折。根据日志,最后一列NHibernate读取似乎有垃圾,它不在底层数据中。什么原因导致NHibernate“内部连接致命”错误?

这个问题似乎消失当任:

  1. 日志级别重新设置为“错误”。
  2. 正在查询的视图被更改为返回的数据较少(对于各个列,可能是较少的行或空值或空值)。

我们使用ASP.NET MVC,IIS7,.NET框架4.5,SQL Server 2012中,log4net.2.0.2和NHibernate.3.3.3.4001。

我想我真正担心的是代码中存在一些隐藏的问题,即日志记录带来的额外负担,但我不确定它会是什么。我有双重检查NHibernate映射,他们看起来不错。我也检查过,以确保在每次请求结束时处理NHibernate会话。我也尝试提高命令超时时间,这似乎没有什么区别。

回答

0

如果其中一列是非简单类型(二进制,文本等),则可能在填充属性时出现问题。

+0

感谢您的快速响应。我只使用以下类型:varchar,datetime,nvarchar和float。 – Brandon

0

发现从我们的开发应用程序服务器到我们的开发数据库服务器的连接是不可靠的。

  1. 从开发应用服务器,打开SSMS并尝试连接到开发数据库服务器。
  2. 有时我们会得到“内部连接致命错误”,有时我们不会。
0

问题可能是由TCP烟囱卸载/ SQL Server不兼容造成的。

检查下面的知识库文章可能的解决方案: http://support.microsoft.com/kb/942861

对于Windows 7/2008 R2:

默认情况下,TCP烟囱卸载功能设置为自动。这意味着 烟囱不会卸载所有连接。而是 有选择地卸载满足以下条件的连接:

该连接通过10千兆比特每秒(Gbps) 以太网适配器建立。

平均往返链路延迟小于20毫秒。

通过 至少130千字节(KB)的数据交换连接。

在数据集中间触发最后一个条件,因此您会看到垃圾而不是实际数据。

相关问题