Lazy Hibernate bei 3-Tier Applikation (JBoss + EJB3 + FatClient)

[daniell82]

Hallo Forum,

ich habe ein kleines Verständnisproblem. Ich baue eine 3-Tier-Applikation aus JBoss, EJB3 und einem Java-FatClient. Die Datenhaltung ist über Entity-Beans realisiert, die Business-Logic über Stateless-Beans. In den Stateless-Beans verwende ich den normalen EntityManager den ich per Injection bekomme. Über Methoden wie findAll() hole ich mir z.B. alle Rechnungen inkl. Rechnungspositionen.

Aktuell verwende ich Eager-Loading und lade mittlerweile einen riesigen Objekte-Baum. Bei Projektbeginn war das natürlich noch kein Problem. Mittlerweile habe ich ewige Ladezeiten.

Meine Idee ist nun auf Lazy-Loading bei den Collections umzustellen. Aber geht das bei einem Fat-Client überhaupt? Wie bekomme ich meine Collections im Nachhinein gefüllt? Meine Session ist ja zu diesem späteren Zeitpunkt bereits wieder geschlossen. Kann mir da jemand auf die Sprünge helfen?

Grüße,
Daniel

 

[maki]

Eager loading ist nicht wirklich die Lösung wie du festgestellt hast, man muss sich wohl oder übel mit der Lazy Load Thematik auseinandersetzen.

Im nachhinein die Collections zu laden halte ich für den nicht so guten Weg, lieber im von vornherein laden
Sog. Fetch Qeuries sollten da benutzt werden, ist nur problematisch beim Einsatz vom Hibernate Cache.

 

[tfa]

Schau mal hier:
http://www.java-forum.org/allgemein...in-object-relationship-mapping-framework.html

Eine Lösung, die geschickt AOP benutzt, um lazy nachzuladen. Allerdings mit Spring

 

[byte]

Sog. Fetch Qeuries sollten da benutzt werden, ist nur problematisch beim Einsatz vom Hibernate Cache.

Problematisch nicht, nur tricky. Per Join Fetch geladene persistente Collections werden problemlos im Cache abgelegt, aber bei einem Cache Hit nicht automatisch wieder rausgeholt. Man muss das manuell anstoßen, bevor man die Entities detached.

 

[daniell82]

Ja, ich habe bereits Fetch-Join verwendet. Ich habe gestern meine abgesetzten Statements überprüft und festgestellt, dass immer noch ziemlich viel mitgeladen wird. Bin dann konsequent vorgegangen und habe die Stamm- und Steuerdatenbeans alle Verbindungen auf Lazy-Loading gestellt. In meinen Bewegungstabellen habe ich alles auf Eager gelassen.

Nun wird im aktuellen Testfall kein Statement mit 1200 Zeilen, sondern nur noch mit 300 Zeilen erzeugt. Die Costs haben sich um den Faktor 1000 verringert.

Nochmal eine Frage zum Caching. Hiermit habe ich mich noch nicht beschäftigt. Bringt der Einsatz spürbare Performanceverbesserungen, oder eher ein Nice-to-have?

 

[FArt]

Nochmal eine Frage zum Caching. Hiermit habe ich mich noch nicht beschäftigt. Bringt der Einsatz spürbare Performanceverbesserungen, oder eher ein Nice-to-have?

Darauf gibt es keine eindeutige Antwort bzw. die Antwort lautet: 42.

Eine bestimmte Caching-Strategie passt zu einem konkreten Problem... und wiederspricht u.U. den Anforderungen eines anderen Problems.
=> Am Anfang ist das Problem, dann kommt wenn nötig und möglich Caching zum Einsatz.

Es gibt keine Aussage: Cache ist immer gut.

 

[byte]

Wenn Du meistens lesend auf die DB zugreifst und keine anderen Anwendungen ausser Deinem Server in die DB schreibt, dann bringt der richtige Einsatz des Second Level Cache massive Performance-Gains.

Ich habe hier Service Calls, die brauchen mit Cache Miss (also mit DB-Zugriff) 1000ms und mit Cache Hit 50ms.