Warum ist NHibernate AutoFlush so teuer?

In der Praxis finden wir den Standard NHibernate (v2.0 & 2.1) FlushMode = Auto, um extrem teuer zu sein. Die Überprüfung der NHibernate-Quelle legt nahe, dass die Algorithmen zum Ermitteln, was gelöscht werden muss, auf Brute-Force-Schleifen durch alle Entitäten in der Sitzung angewiesen sind. Dies geschieht für jede Abfrage, die in einer Transaktion ausgeführt wird.Warum ist NHibernate AutoFlush so teuer?

In einigen Produktionsszenarios mit Updates für viele Elemente mit mehreren Abfragen haben wir den Prozess mit FlushMode = Auto im Vergleich zu FlushMode = Commit 100 Mal länger gesehen.

Alle Gedanken/Beratung/Best Practices für die Verwendung von Flushmode bei ‚komplexen‘ Session-Logik mit Beteiligung mehrerer Updates, mehrere Abfragen usw.

Irgendwelche Ideen Durchführung der Autoflush-Algorithmen in nHibernate auf die Optimierung?

Quelle

2009-11-13 Pawel

damit verbundene Frage: http://stackoverflow.com/questions/1724307/nhibernate-poor-performance-on-auto-flush-events – zvolkov

yep ... eigentlich das gleiche Problem :) – Pawel

Diese Langsamkeit ist ein bekanntes Problem und wird in NH Jira als NH-1365

Es gibt drei Modi bündig in NH verfolgt:

FlushMode.Auto = Flush bei Bedarf (auf begehen und vor Abfragen, wenn benötigt). Dies ist der Standardwert.
FlushMode.Commit = Spülen bei Festschreibung der NH-Transaktion nur
FlushMode.Never = niemals spülen (bis Flush aufgerufen wird). Dies wird still go to DB auf Einfügen von Elementen, die nativen (Identität) PK-Generator verwenden.

Quelle

2009-11-16 17:25:43 zvolkov

Danke, froh zu wissen, es ist ein bekanntes Problem. Traurig zu wissen, dass es seit über einem Jahr ein bekanntes Problem ist! Ich bin mir bewusst, dass es viele Möglichkeiten gibt, Code neu zu arrangieren, um die Anzahl der durchgeführten Flushes zu begrenzen. Nichtsdestotrotz scheint die Spülleistung in Nhibernate viel langsamer zu sein, als es sein sollte. – Pawel

Warum ist NHibernate AutoFlush so teuer?

Antwort

Verwandte Themen