2013-10-30 197 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)的數據交換連接。

在數據集中間觸發最後一個條件,因此您會看到垃圾而不是實際數據。

相關問題