Hibernate: Query Cache und Assoziationen

[byte]

Hallo,

ich benutze als 2nd Level Cache für Hibernate den EHCache und habe auch den QueryCache aktiviert. Ich habe verschiedene Queries, die per LEFT JOIN FETCH direkt Assoziationen mitladen. Dies ist wichtig, weil ich die Hibernate Objekte danach von der Session detache. Ich kann die Assozationen also nicht lazy nachladen.

Es funktioniert alles soweit ganz gut. Die Entitäten werden alle im EHCache abgelegt. Wenn ich das Query zum zweiten Mal ausführe, gibts einen Cache Hit und die Entität wird aus dem Cache geladen statt aus der Datenbank.

Das Problem ist nur, dass die zuvor per LEFT JOIN FETCH mitgeladenen Assozationen nicht direkt aus dem Cache geholt werden. Ich bekomme also nicht den gleichen Objektgraphen aus dem Cache wie beim initialen Laden aus der DB. Die PersistentCollections (in meinem Fall PersistentList) sind nicht initialisiert (initialized = false).

Das Problem habe ich nun erstmal wie folgt gelöst: bevor ich die Objekte detache (vom Server zum Client weiterreiche), rufe ich zunächst alle Assozationen einmal auf. Auf diese Weise werden die PersistentLists initialisiert. Die Objekte werden dabei nicht aus der DB geladen, sondern wie gewollt aus dem Cache geholt.

Ich frage mich nur, obs für dieses Problem auch eine einfachere bzw. bessere Lösung gibt? Ich hätte eigentlich erwartet, dass bei einem QueryCache Hit per Default der selbe Objektgraph aus dem Cache geladen wird, der beim initialen PUT dort abgelegt wurde.

Kann man das irgendwie erreichen? Ist meine Konfiguration vielleicht bloß nicht korrekt?

Ich bin gespannt, ob sich hier jemand mit EHCache Erfahrungen tummelt und mir weiterhelfen kann.

byto

 

[maki]

Hi byto, habe noch nicht mit EHCache gearbeitet, weiss nicht ob ich nützlich sein kann.

Um dein Problem besser zu verstehen:
Nachdem die Objekte zum ersten mal per fetch Query samt zugehörigen "echten" Collections (also nicht als Proxy) geladen hast, liefert dir die 2. fetch query (also die erste fetch query nochmals ausgeführt) die Collections nicht-initialisiert als proxy?

 

[byte]

Ja genau.

Beim ersten mal Cache Miss: FROM ... LEFT JOIN FETCH ... wird ausgeführt und Collections sind keine Proxies. Alle Objekte und Collections des Objektgraphen kommen per PUT in den Cache.

Beim zweiten mal Cache Hit: Es wird kein SQL gefeuert. Stattdessen wird das Objekt aus dem Cache geholt. Collections sind aber Proxies. Ruft man auf dem Proxy Collection#iterator() auf, dann wird der Proxy initialisiert und die Objekte werden aus dem Cache geladen.

Habe hier einen Thread gefunden, wo einer wohl ein ähnliches Problem hat: http://forum.hibernate.org/viewtopic.php?t=955839

 

[maki]

Scheint ein alter und ungelöster Bug zu sein, in deinem Link wird auf den Jira Issue verlinkt [#HHH-1523] LazyInitializationError on enabling query cache... - Hibernate JIRA

Workarounds (d.h. manuelles initialisieren oder 2nd Level Cache abschalten) sind bekannt, aber ein Fix scheint nicht in Sicht zu sein.
Sehr ärgerlich...

 

[byte]

Jo, sieht so aus. Hab mal einen Test mit einem sehr großen Objektgraphen gemacht mit diesem Workaround. Ergebnis: Mit SQL dauerts 700ms, mit Cache und Workaround (Proxy-Collections manuell initialisieren) dauerts 1200ms. Tolle Wurst. :noe:

 

[KSG9|sebastian]

Das Thema lazy-loading, proxies u.s.w. ist allgemein sehr problematisch. Ich hoffe mal dass JPA 2.0 durch Spezifikation von FetchGroups u.s.w. das ganze gescheit löst...

 

[maki]

Betrifft dieses Problem eigentlich auch die anderen Cache Implementierungen die angeboten werden?

Verstehe wirklich nicht warum sich keiner bei Hibernate dieses alten Problems annimmt ...

Das Thema lazy-loading, proxies u.s.w. ist allgemein sehr problematisch. Ich hoffe mal dass JPA 2.0 durch Spezifikation von FetchGroups u.s.w. das ganze gescheit löst...

Naja, die offizielle Standard Lösung für JPA 1.0 lautet eben fetch joins, wenn die Cache Implementierungen diese nicht unterstützen, nutzt eine Erweiterung in JPA 2.0 auch nicht viel..

 

[byte]

Es liegt wohl einfach daran, wie der QueryCache implementiert ist. Der merkt sich nämlich nur die IDs der Entities. Bei einem Cache Hit legt er dann einen Collection Proxy an, ohne direkt alle Entities aus dem Cache zu holen. Das macht ja auch erst dann Probleme, wenn man die Entities detachen will. Wenn man das nicht macht, werden die Objekte halt lazy aus dem Cache geholt, wenn sie gebraucht werden.

Das Problem ist, wenn man die Collections alle manuell initialisiert, scheint es bei sehr vielen Objekten doch recht langsam zu sein. Verstehe aber nicht so recht warum. :bahnhof:

 

[maki]

Es liegt wohl einfach daran, wie der QueryCache implementiert ist. Der merkt sich nämlich nur die IDs der Entities. Bei einem Cache Hit legt er dann einen Collection Proxy an, ohne direkt alle Entities aus dem Cache zu holen. Das macht ja auch erst dann Probleme, wenn man die Entities detachen will. Wenn man das nicht macht, werden die Objekte halt lazy aus dem Cache geholt, wenn sie gebraucht werden.

Solange eine Cache Implementierung keine Fetch joins und damit die gewünschte Initialiseriung von Objekten berücksichtig, wird es zu Problemen kommen, egal ob mit oder ohne detached objects.
Denke dabei an den Performance Vorteil von fetch joins, nämlich alles auf einmal aus der DB zu holen der damit zunichte gemacht wird.

Das Problem ist, wenn man die Collections alle manuell initialisiert, scheint es bei sehr vielen Objekten doch recht langsam zu sein. Verstehe aber nicht so recht warum.

Vermute weil für jede initialisierung ein einzelnes SQL Select abgesetzt wird..

 

[byte]

Ich habe oben Blödsinn geschrieben, dass der der Cache Hit bei großen Graphen langsamer ist. Man sollte keine Performance-Tests machen mit Loglevel DEBUG. ^^

Nun bei deaktiviertem Cache Logging siehts so aus: Erster Aufruf vom Service (mit Datenbankabfrage) dauert ~250ms. Alle weiteren Aufrufe des Service (mit Cache) dauern ~25ms.

Die Initialisierung der Collections habe ich rekursiv per Reflectiong gelöst, so dass es für beliebige Objektgraphen funktioniert und nicht jedes mal neu implementiert werden muss.

Solange eine Cache Implementierung keine Fetch joins und damit die gewünschte Initialiseriung von Objekten berücksichtig, wird es zu Problemen kommen, egal ob mit oder ohne detached objects.
Denke dabei an den Performance Vorteil von fetch joins, nämlich alles auf einmal aus der DB zu holen der damit zunichte gemacht wird.

Der EHCache reproduziert nicht die Collection, das ist richtig. Aber wenn Du die Collection nach einem Cache Hit dann initialisierst, wird ja kein SELECT abgefeuert. Stattdessen werden die Elemente der Collection aus dem Cache geholt. Du hast also keinen Nachteil dadurch, dass die Collection ein Proxy ist, ausser Du detached das Objekt.

 

[maki]

Achso