Hibernate LazyInitialization

[Guest]

Ich habe eine Service-orientierte Archtitektur und verwende keine eigenen DataTransfer-Objekte sondern dieselben die auch in die Datenbank gespeichert werden.
Typischerweise hat man hier bei Hibernate LazyInitialization bei Referenzen auf andere Objekte, da ich die Objekte aber übers Netz versende kann natürlich später nicht mehr nachgeladen werden.

Habe schon viel zu dem Thema gelesen aber kann mir nicht vorstellen das es dazu nicht eine bessere Lösung gibt?
Gefunden habe ich:
1. gar kein LazyInitialization benutzen
2. vor dem versenden manuell per getXXXXX() Methode auf alle datenelemente zugreifen die per LazyInitialization gemanaged werden (fehleranfällig und kostet Performance)
3. Irgendwas mit Session auch auf anderen PC übertragen bzw. zugreifbar machen (scheinbar sehr aufwendig und fehleranfällig?)


a) Gibts denn nicht einfach eine Möglichkeit vor dem versenden sowas wie "session.loadEager(obj)" aufzurufen wobei Hibernate dann automatisch ALLES aus der Datenbank lädt was in dem Objekt noch nicht initialisiert wurde?
Vielleicht auch mehrstufig? D.h. Auftrag hat ein Feld "Kunde", dieser hat eine "Adresse" welche wiederrum irgendwelche Felder hat usw. (nur als Beispiel)

b) Auch würde ich manchmal gerne die Lazy/Eager Anweisung "überschreiben", d.h. bei instatiierung des Objektes Hibernate mittteilen das es die Anweisungen in der Klasse (annotations) ignorieren soll und gleich ALLES Eager laden soll. Geht das?
Beispiel: Eine Klasse hat ein Attribut das nur zu statistischen zwecken verwendet wird, dies wird im Regelbetrieb nur sehr selten verändert (sowas wie der Lieferant der diesen Artikel liefert). Bei einer statistischen Auswertung laufe ich aber über den kompletten Datenbestand und muss von allen Artikeln dieses Feld auslesen => unnötige Datenbankabfragen, könnte gleich alles mitgeladen werden. D.h. gerade wenn Performance gefragt ist verfielfachen sich möglicherweise die Datenbankabfragen...


Habe den Eindruck das LazyInitialization ohne gutes Konzept schnell mehr Performance kostet als es bringt? Arbeitsaufwand/Fehlersuche/... kommt auch noch hinzu...
Daher frage ich mich ernsthaft ob ich nicht gleich darauf verzichten soll? Habe nur ein einziges Objekt das eine Referenz auf ein aufwendig zu ladendes/großes Objekt verweist (nämlich auf eine EMail die mit Anhang schonmal ein paar Megabyte hat, meist aber nur <50kB)


Wäre für ein paar Tipps dankbar!

 

[foobar]

Ja, das Problem kennt wohl jeder, der sich mit Hibernate auseinander setzt.
Es gab schon einige Diskussionen dau:
http://www.java-forum.org/de/viewtopic.php?t=67346&highlight=hibernate+preload
http://www.java-forum.org/de/viewtopic.php?t=66555&highlight=hibernate+preload
http://www.java-forum.org/de/viewtopic.php?t=66958&highlight=hibernate+lazy

Auch würde ich manchmal gerne die Lazy/Eager Anweisung "überschreiben", d.h. bei instatiierung des Objektes Hibernate mittteilen das es die Anweisungen in der Klasse (annotations) ignorieren soll und gleich ALLES Eager laden soll. Geht das?

Ja, das geht mit Criteria Queries:

DetachedCriteria det      = DetachedCriteria.forClass(UnternehmerBean.class);
        det.add(Restrictions.like("name1", "%"+name+"%"))
        .setFetchMode("rechnungen", FetchMode.DEFAULT)
        .setFetchMode("zahlungen", FetchMode.DEFAULT)
        .setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);

        List<UnternehmerBean> out =  getHibernateTemplate().findByCriteria(det);
        return out;

Mit setFetchMode kannst du für jeden Member bestimmen wie dieser initialisiert werden soll.

 

[byte]

zu a) Hibernate bietet afaik keine solche Möglichkeit. Du bist selbst dafür verantwortlich, welche Daten geladen werden und wie das bewerkstelligt wird. Möchtest Du einen gesamten Objektgraph laden, dann kannst Du - wie schon selbst festgestellt - einen Mechanismus schreiben, der alle Getter im Objektgraph einmal aufruft. Per Reflection kann man das problemlos für beliebige Objektgraphen realisieren. Allerdings ist diese Möglichkeit alles andere als performant, wegen des N+1 SELECT Problems (pro Lazy Loading wird ein SELECT abgesetzt). Besser ist es, die Daten per JOIN direkt zu laden. Dafür gibts dann aber nicht mehr ohne weiteres eine allgemeingültige Implementierung, die für jeden Anwendungsfall praktikabel ist.

Lange Rede kurzer Sinn: Es ist am sinnvollsten, für jeden Usecase zu analysieren, welche Daten gebraucht werden und dann gezielt per Criteria oder HQL den richtigen Objektgraphen zu laden.

Habe den Eindruck das LazyInitialization ohne gutes Konzept schnell mehr Performance kostet als es bringt? Arbeitsaufwand/Fehlersuche/... kommt auch noch hinzu...

Jein. Die Problematik besteht nur, wenn die Session geschlossen ist. Bei Web-Anwendungen und dem Open-Session-In-View Pattern wirst Du nie eine LazyInitExc sehen. Arbeitet man aber mit Detached Entities, dann ist das LazyInit-Problem das zentrale Problem, dass es so früh wie möglich zu lösen gilt. Die Lösung ist aber wie gesagt abhängig vom Anwendungsfall.