Ich habe ein extrem bizarres Verhalten bekommen, wo NHibernate-Abfragen zu hängen beginnen. Ich habe ein Demo-Projekt gemacht, das dieses Verhalten auf wiederholbare Weise zeigt.NHibernate's criteria.List() hängt, wenn faule Eigenschaft auf Entität existiert
können Sie das Projekt herunterladen here
Hier ist der säumige Code:
public IList<Post> GetLatestLiveBlogEntries(int numEntriesToRetrieve)
{
var maxDate = DateTime.Now;
using (var session = SessionManager.OpenSession())
{
var crit = session.CreateCriteria(typeof (Post))
.Add(Restrictions.Eq("Enabled", true))
.Add(Restrictions.Lt("postDate", maxDate))
.AddOrder(new Order("postDate", false))
//.SetFetchMode("author", FetchMode.Eager) // <-- the exclusion of this line breaks everything!
.SetMaxResults(numEntriesToRetrieve);
StupidFileLogger.Log("If this is the last log, I'm hanging on crit.List<Post>()");
var listOfPosts = crit.List<Post>();
StupidFileLogger.Log("I actually was able to retrieve the posts");
return listOfPosts;
}
}
Der Schlüssel Linie ist die .SetFetchMode auf dem Autorenfeld. Beim ersten Laden meines Demo-Projekts wird es gut geladen. Wenn ich auf Aktualisieren klicke, bleibt es hängen und kommt nie über den Aufruf crit.List() hinaus. Mit eifrigem Laden funktioniert es jedes Mal.
Ich verwende Castle.Facilities.NHibernateIntegration.Components.SessionWebModule, um eine Sitzung pro Anfrage zu gewährleisten.
Die andere seltsame Sache, die ich gefunden habe, ist, dass dies nur mit SQL Server geschieht. Wenn ich SQLite verwende, funktioniert alles gut. In meinem Demo-Projekt habe ich ein einfaches Build-Flag, mit dem Sie einfach db's wechseln können. Sehen Sie sich die Datei local.properties.xml im Verzeichnis/build an.
Ich verstehe, dass eifrig laden löst mein Problem in diesem speziellen Fall, aber in meiner Anwendung möchte ich nicht unbedingt alles laden müssen.
Bitte laden Sie die Lösung herunter und versuchen Sie es selbst. Ich habe es auf anderen Maschinen ausprobiert und sie machen das Gleiche.
Hier sind einige SQL Profiler-Captures. Sie können sehen, dass die Abfrage Beiträge wurde an den Server gesendet, aber es hält dort:
erste Anfrage (verhält sich wie erwartet):
good request http://muc-central.com/misc/good_request.jpg
Zweite Anfrage (Hänge):
Wie lange haben Sie es verarbeitet? Sind Sie sicher, dass es tatsächlich hängt und nicht nur für eine lange Zeit sehr beschäftigt? Haben Sie sich NH Profiler angeschaut, um zu sehen, was NH macht, wenn Sie die Liste <> das zweite Mal aufrufen? –
Ich habe es gelassen, während ich zum Mittagessen gegangen bin und es immer noch nicht fertig war. Ich habe es mit NHProf getestet und ich kann sehen, dass die Abfrage den DB-Server traf. Ich kann auch durch den SQL Server Profiler erzählen. –