是什么导致NHibernate“内部连接致命”错误?

时间:2013-10-30 19:13:22

标签: sql-server nhibernate log4net

当NHibernate的日志级别设置为“DEBUG”时,我们会在日志中看到一堆“内部连接致命”错误。看起来NHibernate通过处理特定的结果集大约½。根据日志,NHibernate读取的最后一列似乎有垃圾,不在底层数据中。

以下任何一个问题似乎都会消失:

  1. 日志级别设置回“ERROR”。
  2. 要查询的视图将更改为返回更少的数据(更少的行OR null或各列的空值)。
  3. 我们使用的是ASP.NET MVC,IIS7,.NET Framework 4.5,SQL Server 2012,log4net.2.0.2和NHibernate.3.3.3.4001。

    我想我真正关心的是代码中存在一些隐藏的问题,即增加的日志记录正在被曝光,但我不确定它是什么。我仔细检查了NHibernate映射,它们看起来很好。我还检查过以确保在每个请求结束时处理NHibernate会话。我也尝试提高命令超时,这似乎没有什么区别。

3 个答案:

答案 0 :(得分:0)

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

答案 1 :(得分:0)

原来从我们的开发应用服务器到我们的开发数据库服务器的连接很不稳定。

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

答案 2 :(得分:0)

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

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

对于Windows 7/2008 R2:

  

默认情况下,TCP Chimney Offload功能设置为Auto。这意味着   烟囱不卸载所有连接。相反,它   有选择地卸载符合以下条件的连接:

     

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

     

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

     

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

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

相关问题