EJB Persistence mit Java Standard Edition (2. Teil)

Im ersten Teil dieser Einführung wurden die Grundlagen für das Persistieren eines Objekts mit EJB3-Persistence besprochen, das auch als Java Persistence API (JPA) bekannt geworden ist. Es gibt einfache Person- und Adress-Klassen, die mit Hibernates EntityManager/Annotations-Implementierung persistiert werden und die in einer eingebetteten HSQLDB persistent werden. Die Beziehung zwischen Person und Adresse ist jedoch unidirektional: Eine Person zeigt auf eine Adresse, es geht nun also darum, wie man das Mapping bidirektional macht. Eine Reihe von Personen, die unter der Adresse wohnen – die residents (Bewohner) -, werden der Adress-Klasse hinzugefügt.

Jetzt kann eine Adresse auf viele Personen zeigen, daher werden die access-Methoden für die residents durch eine @OneToMany-Annotation ergänzt:

Wenn man nun eine Adresse für eine Person setzt, um die Beziehung zu erhalten, erhält man die residents und fügt die Person der Gruppe hinzu – sofern man nicht versucht hat, mit dem Beispielcode, der letzten Monat eingeführt wurde, auf die Bewohner einer Adresse zuzugreifen …

Dann erhält man nämlich eine Lazy-Initialisation-Fehlermeldung, bevor man überhaupt daran dachte, die Änderung persistent zu machen. Sammlungen werden nicht gefetcht, wenn man ein Adress-Objekt aufruft. Sie werden nur dann aufgerufen, wenn man tatsächlich auf das Feld zugreift. Das ist Lazy Initialisation.

Doch kann Lazy Initialisation nur dann geschehen, wenn das Objekt nicht vom EntityManager gelöst wurde. Mit dem Code vom letzten Monat wurden gelöste Objekte herumgereicht, weil der EntityManager bei jeder neuen Datenzugriffsmethode erzeugt und geschlossen wurde. Das kann man jetzt umgehen, indem man die Annotation der residents ändert zu:

Dadurch wird jedoch die Persistenzschicht dazu gezwungen, immer alle verbundenen Daten zu fetchen, wenn das Objekt aufgerufen wird. Und das ist als allgemeines Prinzip nicht empfehlenswert – die übermäßige Verwendung kann dazu führen, dass große Objektbäume in den Speicher geladen werden. Wenn man das Laden erzwingen möchte, kann man dafür das EJBQL-Fetch-Keyword verwenden. Man kann die Suche zu findByPostcode ändern und left join fetch address.residents hinzufügen, um das Laden der residents-Eigenschaften auf diese Weise zu erzwingen: