0

当 NHibernate 的日志级别设置为“DEBUG”时，我们开始在日志中看到一堆“内部连接致命”错误。看起来 NHibernate 在处理特定结果集时会以大约 ½ 的方式死亡。根据日志，NHibernate 读取的最后一列似乎有垃圾，而这些垃圾不在基础数据中。

在以下情况下，问题似乎消失了：

  1. 日志级别设置回“错误”。
  2. 被查询的视图被更改为返回更少的数据（更少的行或者各个列的空值或空白值）。

我们正在使用 ASP.NET MVC、IIS7、.NET Framework 4.5、SQL Server 2012、log4net.2.0.2 和 NHibernate.3.3.3.4001。

我想我真正担心的是代码存在一些隐藏的问题，日志记录的额外压力正在暴露出来，但我不确定它可能是什么。我已经仔细检查了 NHibernate 映射，它们看起来不错。我还检查以确保我在每个请求结束时处理 NHibernate 会话。我还尝试增加命令超时，这似乎没有什么不同。

4

3 回答 3

0

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

  1. 从开发应用服务器，打开 SSMS 并尝试连接到开发数据库服务器。
  2. 有时我们会收到“内部连接致命错误”，有时我们不会。
于 2013-10-30T21:02:06.613 回答
0

如果其中一列是非简单类型（二进制、文本等），nh 可能在填充属性时遇到问题。

于 2013-10-30T19:21:26.323 回答
0

问题可能是由 TCP Chimney Offload/SQL Server 不兼容引起的。

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

对于 Windows 7/2008 R2：

默认情况下，TCP 烟囱卸载功能设置为自动。这意味着烟囱不会卸载所有连接。相反，它会选择性地卸载满足以下条件的连接：

连接是通过每秒 10 吉比特 (Gbps) 的以太网适配器建立的。

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

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

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

于 2014-01-31T14:20:48.113 回答