hallo!
wir verwenden hibernate2.1 innerhalb eines batch-jobs der
n-mal folgenden loop durchläuft:
*) eine menge daten von der db lesen...
*) einige berechnungen damit anstellen...
*) das ergebnis wieder in die db schreiben (1-5 rows)

beim beginn des jobs sind die hibernate-services noch sehr flott. im laufe der zeit jedoch nimmt die laufzeit der services (z.b. einzelne selects) ständig zu. db-seitig ist das nicht zu erklären, da dort alles schnell abgearbeitet wird.
ein vm-profiler ergab jedoch, dass immer mehr zeit von den hibernate-flushes konsumiert wird. weiters steigt der instance-count von IdentityMapEntry und IdentityKey stark an (wird aber vom immer öfter laufenden gc wieder weggeräumt).

warum wird das flushing immer langsamer? was könnte man dagegen tun?

ein experiment zeigte, dass bei
"session.setFlushMode(Flushmode.COMMIT)"
in unserem fall eine deutliche performancesteigerung bringt. kann die verwendung dieses flushmodes nachteile haben? wenn ja, in welcher art.

bitte um unterstützung!

Lies einfach die Dokumentation. Da gibts ein komplettes kleines Kapitel ueber Batch Operationen.

die Dokumentation (Kap. 9.6 Flush ?!) gibt leider nur geringfügig Infos
darüber, eine kurze Erläterung findet statt, aber wirklich Aufschluss über
die Arbeitsweise der Flushmodes gibt das hier nicht.
Eine Erläuterung dieser Modis ist vielleicht besser in der API(?!) nachzulesen.

Eine Antwort auf die vorhergehende Frage konnte ich leider daraus nicht
entnehmen, allerdings stellt dies schon ein interessantes 'Problem' bei
zeitkritischen Prozessen dar.

Dein Beispiel ist komplett erklaert, Zeile fuer Zeile. Ja, die API Dokumentation sollte man auch lesen...

Die Aussage (in Kap. 9.6) " This is most useful in the case of "readonly" transactions" ist doch nur ein kleiner Hinweis?!

Offene Fragen wären (für mich z.b.), ist es sinnvoll eine Änderung des Flushmodes während der Laufzeit von bestimmten 'Tabellen' abhängig zu machen (also bei read- writeoperationen diesen zu switchen)?!

Wenn ja, wie verhält sich das dann bei mehreren Prozessen?!
Der eine Thread liest z.B. nur, ein anderer schreibt und liest -
beide nutzen aber dieselbe Session ( <-ist das günstig? ), so
könnte ein hin-herschalten den Performancegewinn wieder zu
nichte machen?!


mfg CC

Du kannst machen was du brauchst/willst... Davor halt verstehen was es macht.

1.) Das switchen zwischen den FLUSHMODEs kann sinnvoll sein.
2.) SessionFactory ist threadsicher, aber Session (leider) nicht!!!
3.) Ja, sinnvoll nur eine Session zu benutzen

Vielleicht beugt das den Fehlern vor ... die ich hatte ;)

*huestel* Das steht alles im ersten Abschnitt im Kapitel "Transactions" ;)

Jaja, so ist das halt.... allerdings hab' ich die Referenz schon öfter durch,
nur Wort für Wort ist nicht so das non-plus ultra, zumal ein Lesen nicht gleich
bedeutet, dass man alles versteht, behält und anwenden kann.

Nicht jeder kennt die Doku, scheinbar wie Du, Wort für Wort.
Eine Antwort "siehe Kapitel ... Abschnitt ... " hätte auch gereicht
und wenn das so klar war, denn hättest Du die 'Antwort' auch
eher posten können *g*

Denn kann ich noch sagen, dass mit den Sessions an sich ist schon
etwas komplizierter und wenn dann noch Threads der Applikation
hinzukommen, ist der Abschnitt sicher ein Hinweis auf die Handhabung
etc. allerdings keine Klärung aller offener Fragen die sich bezüglich dieses
Themas stellen.

Generell kann ich nur sagen, Deine Antworten sind nicht so die Messe -
weder auf meine, noch auf andere Fragen die ich hier gelesen habe.
Mit dem Hinweis "steht alles in der Doku" o.ä. ist meistens keinem geholfen,
einem Neueinsteiger erst recht nicht!

Solche werden durch diese Forumhandhabung eher abgeschreckt,
ist Dir aber sicherlich egal - mir auch, dass soll mich von der Nutzung
Hibernate's nicht abhalten. Du wirst schon wissen was Du machst ;)

Jo, ich bin immer wieder dankbar wenn ich Leute darauf hinweisen ihnen in meiner Freizeit noch netter zu helfen. :)