LazyInitializationException - Warum?

[Tobias]

Hi,

ich bekomme eine LazyInitializationException, die ich mir nicht so recht erklären kann ... Den Thread von byto (http://www.java-forum.org/de/topic66555_lazyinitializationexception-vs-dtos.html) habe ich gelesen, steige da aber nicht so recht durch.

Zum konkreten Problem:
Ich habe eine kleine PersistenceBean-Hierachie, mit einer Basisklasse FileBase und zwei Unterklassen XULFile und BinaryFile. Die Basisklasse FileBase enthält eine Collection von "Roles", die ein die Dateien abrufender User haben muss, um die Datei ansehen zu dürfen.

+----------+              +-------+
| FileBase |<>------------| Roles |
+----------+              +-------+
       ^
       |
       +---------------+
       |               |
+---------+       +------------+
| XULFile |       | BinaryFile |
+---------+       +------------+

XULFile und BinaryFile werden nicht detached, sondern von meinem Swing-Client nur nach ihren Inhalten befragt, die sie als String bzw als byte[] zurückliefern. Trotzdem erhalte ich stets eine

javax.ejb.EJBTransactionRolledbackException: failed to lazily initialize a collection of role: de.tobiasdemuth.cube.server.xul.FileBase.accessAllowed, no session or session was closed

Ich habe schon versucht den FetchType von accessAllowed, also der Roles-Collection, auf EAGER zu setzen, der Fehler bleibt jedoch der gleiche.

Wonach muß ich suchen? Woher kommt dieser Fehler? Was kann ich versuchen, um dieses Problem abzustellen?

mpG
Tobias

 

[byte]

Ich kenne mich mit EJB nicht aus, aber woher weisst Du, dass die Entität nicht detached ist? Wenn Du Hibernate Objekte vom Server zu Deinem Swing Client weiterreichst, dann sind sie mit Sicherheit detached, also ausserhalb der Session.
Die LazyInitializationException kommt immer dann, wenn ein Property für Lazy Loading konfiguriert ist (also erst beim Aufruf aus der DB geladen wird), die Hibernate Session jedoch zu - das Objekt also detached ist.
Wenn Du das Property auf EAGER Loading setzt, dann sollte es eigentlich nicht zu dieser Exception kommen.

 

[maki]

Stimme byto 100% zu, wenn sie nciht detached wären, würdest du die Execption nicht bekommen.

 

[Tobias]

Das ist es ja eben - die FileBase-Klassen werden nicht an den Client ausgeliefert, sondern durch eine Session-Facade nach ihren Inhalten befragt. Diese Session-Facade stellt dann auch gleich sicher, dass der nachfragende User überhaupt die Berechtigung besitzt, die entsprechende Datei einzusehen. Und an der Stelle knallt's.

Oder werden PersistentBeans schon detached, wenn eine SessionBean sie anfragt?

mpG
Tobias

P.S.: EAGER-Loading habe ich so umgesetzt (Die Role-Objekte haben nur primitive bzw String- Properties und sie werden bei jedem Aufruf gebraucht - von daher ist EAGER wahrscheinlich eh die bessere Wahl):

@Basic(fetch=FetchType.EAGER)
private Set allowedRoles;

Das steht so in FileBase. Bin ein Noob was EJBs angeht, also möglicherweise mache ich auch was grundsätzliches verkehrt.

 

[benders]

Hi!

Hast Du Statefull oder Stateless Sessionbeans benutzt?

Bernd

 

[Tobias]

Eine stateless Session-Bean. Könnte es vielleicht etwas damit ztu tun haben, dass ich einen Interceptor installiert habe, der vom Client übergebene User-Objekte auf Gültigkeit prüft?

mpG
Tobias

 

[Tobias]

Okay,

nachdem ich die EAGER-Loading-Deklaration an den Getter gehängt habe (zu all den anderen Annotationen ), geht es jetzt. Ich würde trotzdem gerne wissen, wo und warum meine Entities detached werden ...

mpG
Tobias

 

[byte]

Die Objekte sind detached, sobald die Hibernate Session geschlossen wird. Wann das bei Dir passiert, kann ich Dir nicht sagen, ohne näheres über dein Projekt zu wissen. Schätzungsweise geht sie nach dem Commit der Transaktion zu.