Die Grenze des Persistenzkontexts

1. LazyInitializationException und Grenzen

Wenn Sie zum ersten Mal eine LazyInitializationException fangen, fühlt es sich meist so an: »Ich habe doch nur getItems() gemacht – warum stürzt alles ab?« Und das ist eine normale Reaktion: Der Java-Code sieht harmlos aus, und plötzlich mischt sich die Datenbank in Ihr Privatleben ein. Wichtig ist, das Denken umzustellen: Die Ausnahme geht nicht »um einen Getter«, sondern darum, dass der Getter versucht, SQL auszuführen, aber nicht mehr die Berechtigung und technische Möglichkeit dazu hat.

Stellen Sie sich vor, Sie haben eine Bestellung CustomerOrder, und die Bestellpositionen (OrderItem) werden lazy geladen. Im Inneren des Bestellobjekts sieht das wie ein normales Feld items aus, aber tatsächlich liegt dort ein spezieller „Wrapper“ (eine lazy-Collection). Solange Sie ihn nicht anfassen, ist alles ruhig. Sobald Sie etwas tun, das echte Daten erfordert (z. B. size() oder Iteration), sagt Hibernate: »Oh, Sie brauchen die Elemente – ich hole sie sofort aus der DB.« Und hier ist der entscheidende Punkt: Auf die DB kann nur zugegriffen werden, wenn eine offene „Arbeitsumgebung“ des ORM vorhanden ist.

Eine typische Meldung sieht in etwa so aus (der Text kann variieren, aber die Bedeutung ist dieselbe):

org.hibernate.LazyInitializationException: failed to lazily initialize a collection
of role: com.example.shopdatajpa.ordering.entity.CustomerOrder.items
could not initialize proxy - no Session

Die Worte „no Session“ sind das Wichtigste in dieser Meldung. Hibernate sagt wörtlich: »Ich wollte Daten nachladen, aber ich habe keine Session (Kontext) mehr, über die ich SQL ausführen kann.« Das ist kein zufälliger Fehler und kein »kommt mal vor«. Es ist fast immer das zwangsläufige Ergebnis, wenn wir die Grenze des persistence context verlassen haben.

2. Die Grenze des persistence context

Es ist sehr verlockend zu denken, dass der persistence context etwas »im Repository« oder »in Hibernate« ist. In der Praxis ist er an den Lebenszyklus der Datenarbeit gebunden, und in unserem Kurs wiederholen wir ständig: Diesen Lebenszyklus bestimmt die Servicemethode, die mit @Transactional markiert ist. Das heißt, meistens wird der persistence context beim Eintritt in die Servicemethode geöffnet und beim Verlassen geschlossen. Hibernate ist nicht bockig; es befolgt einfach Ihren Vertrag.

Halten wir ein einfaches Weltbild fest. Wenn Spring einen Aufruf einer Methode mit @Transactional sieht, tut es (über einen Proxy) ungefähr Folgendes: Es öffnet eine Transaktion, erstellt/verknüpft einen EntityManager (und damit die Hibernate-Session), führt Ihren Code aus, führt dann einen Commit/Rollback durch und schließt den Kontext. Danach sind die Entitäten, die Sie geladen haben, nicht mehr managed, sondern werden detached. Sie sind immer noch normale Java-Objekte, aber aus Sicht des ORM nicht mehr „lebendig“.

Das können wir in einer kleinen Tabelle festhalten, um nicht im Nebel zu stochern:

Und an diesem Punkt ist ein kurzer, aber ehrlicher Gedanke hilfreich: Lazy Loading ist ein „Feature innerhalb der Transaktion“. Außerhalb der Transaktion (genauer: außerhalb des offenen persistence context) wird Lazy Loading zu einer „gefährlichen Illusion“: Die Beziehung existiert scheinbar, der Getter existiert scheinbar, aber unter der Haube fehlt der Mechanismus, der SQL ausführen kann.

Um die Kausalität anschaulicher zu machen, hier ein Sequenzdiagramm der Ereignisse:

sequenceDiagram
    participant Client as Externer Code
    participant Service as "OrderService (@Transactional)"
    participant Repo as OrderRepository
    participant DB as PostgreSQL

    Client->>Service: findOrder(1L)
    Note over Service: Transaktion und Persistenzkontext werden geöffnet
    Service->>Repo: findById(1L)
    Repo->>DB: SELECT ... FROM customer_order WHERE id=1
    DB-->>Repo: Bestellzeile
    Repo-->>Service: "CustomerOrder (managed)"
    Note over Service: Methode endet → Commit, Kontext wird geschlossen
    Service-->>Client: "CustomerOrder (detached)"
    Client->>Client: order.getItems().size()
    Note over Client: SQL wird benötigt, aber Session ist nicht mehr vorhanden
    Client-->>Client: LazyInitializationException

Beachten Sie das Detail: Der Fehler wird nicht vom Repository und nicht vom Service ausgelöst. Der Fehler wird vom Client-Code ausgelöst, der nach dem Schließen des Kontexts versucht, „noch einen kleinen SQL“ auszuführen. Hibernate muss ablehnen.

3. EAGER – eine schlechte Standardstrategie

Wenn Studenten zum ersten Mal auf LazyInitializationException stoßen, suchen sie oft verzweifelt nach einem Zauberspruch, der dafür sorgt, dass es nie wieder abstürzt. Und dann betritt EAGER die Bühne als fragwürdiger Superheld. Theoretisch ist die Logik einfach: »Wenn die Beziehung sofort geladen wird, gibt es später kein Lazy Loading, also auch keine Ausnahme.« In der Realität tauscht man damit sehr schnell ein vorhersehbares Problem gegen eine Reihe viel komplizierterer Probleme ein.

Erstens zwingt EAGER Hibernate, die zugehörige Entität oder Collection jedes Mal zu laden, auch wenn das konkrete Szenario sie gar nicht benötigt. Sie zahlen also für Daten, die Sie „auf Reserve“ halten. Das ist, als würde man eine Pizza für eine Woche im Voraus bestellen, „nur für den Fall“ – klingt optimistisch, aber der Kühlschrank leidet.

Zweitens kann EAGER bei Collections (OneToMany) zu sehr teuren Abfragen und einer unerwarteten Aufblähung des Ergebnisses führen. Auch wenn Sie nicht ins Detail von SQL gehen, ist es intuitiv wichtig zu verstehen: Wenn Sie „immer die Kinder zusammen mit dem Elternteil laden“, riskieren Sie eine riesige Datenmenge, wo Sie nur die Bestellüberschrift (Nummer und Summe) brauchten. Das Szenario „Liste der Bestellungen“ wird sofort zum Szenario „Liste der Bestellungen + aller Positionen jeder Bestellung“, was eine ganz andere Kosten-Nutzen-Rechnung ist.

Drittens garantiert EAGER nicht, dass das Problem für immer verschwindet. Heute machen Sie eine Beziehung eager, morgen fügen Sie eine zweite hinzu, dann eine dritte, dann haben Sie noch eine weitere Verschachtelungsebene. Irgendwann laden Sie einfach „fast alles“ ohne Kontrolle, und die Anwendung wird unerwartet langsam, speicherhungrig und extrem schwer zu analysieren.

Deshalb ist EAGER keine Behandlung der Ursache, sondern der Versuch, „die Lampe am Armaturenbrett zu überkleben“, damit sie nicht stört. LazyInitializationException ist nützlich, weil sie laut sagt: »Du versuchst, Daten außerhalb der richtigen Grenze zu lesen.« Und anstatt die Ausnahme zum „Schweigen“ zu überreden, ist es meist besser, das architektonische Verhalten zu ändern: Wo genau lesen Sie die benötigten Daten, und was geben Sie nach außen zurück?

4. Zugriff auf lazy-Daten innerhalb der Transaktion

Die gute Nachricht ist: LazyInitializationException wird nicht durch Schamanismus geheilt, sondern durch Grenzdisziplin. Wir haben bereits die Regel „Ein Use Case – eine Transaktion“ eingeführt, und jetzt zeigt sich eine unerwartete Seite: Die Transaktion wird nicht nur zum Schreiben benötigt, sondern auch zum korrekten Lesen, wenn das Lesen lazy-Beziehungen umfasst. Und der einfachste praktische Tipp ist: Geben Sie nach außen keine Entität weiter, die später jemand „anzapfen“ wird.

Der sicherste Stil für Anfänger lautet: „Innerhalb der Transaktion lese ich alles, was für das Szenario nötig ist, und gebe nach außen keine Entität zurück, sondern ein einfaches Ergebnis.“ Das kann ein String, eine Zahl, ein kleines DTO/record sein. Wenn wir zum Beispiel einen „Zähler der Positionen in einer Bestellung“ brauchen, sollten wir nicht die Bestellung zurückgeben und später zählen – wir zählen innerhalb der Transaktion:

import org.springframework.transaction.annotation.Transactional;

@Transactional(readOnly = true) // Innerhalb der Methode ist der Persistenzkontext geöffnet (LAZY-Beziehungen sind zugänglich)
public int countOrderItems(Long orderId) {
    CustomerOrder order = orderRepository.findById(orderId).orElseThrow(); // Entität wird managed
    return order.getItems().size(); // Beim ersten Zugriff auf items kann Hibernate SQL ausführen
}

Hier wird size() innerhalb des offenen persistence context ausgeführt. Hibernate führt problemlos SQL für die Collection aus, und Sie geben einen einfachen int zurück, der nichts mehr nachlädt. Das ist eine langweilige Lösung. Und eine langweilige Lösung im Backend ist oft ein Kompliment.

Wenn Sie statt einer Zahl eine kleine „Bestellüberschrift“ zurückgeben möchten, können Sie diese als record zusammenstellen. Das passt wunderbar zu Java 25: Ein record ist kurz, lesbar, sieht nicht wie ein vollwertiges „zweites Domänenmodell“ aus, löst aber die Aufgabe, keine JPA-Entität nach außen zu tragen.

// DTO für die Ausgabe: kein Entity, benötigt keinen Persistenzkontext
public record OrderHeader(String orderNumber, int itemCount) {}

Und die Servicemethode:

import org.springframework.transaction.annotation.Transactional;

@Transactional(readOnly = true) // Lesegrenze + Ort, an dem LAZY-Collections sicher initialisiert werden können
public OrderHeader findOrderHeader(Long orderId) {
    CustomerOrder order = orderRepository.findById(orderId).orElseThrow(); // managed innerhalb der Transaktion
    int count = order.getItems().size(); // Die Initialisierung der LAZY-Collection erfolgt hier, nicht außerhalb
    return new OrderHeader(order.getOrderNumber(), count); // Nach außen geht ein „flaches“ Ergebnis
}

Beachten Sie: Wir diskutieren keine „speziellen Ladetechniken“, rühren keine Web-Ebene an und versuchen nicht, Hibernate auf magische Weise zu konfigurieren. Wir nutzen einfach ehrlich das, was wir bereits gelernt haben: Die Transaktionsgrenze liegt im Service, und die gesamte Logik, die lazy-Beziehungen betreffen könnte, muss innerhalb dieser Grenze stattfinden.

Und hier kommt ein wichtiger, erwachsener Gedanke (ohne Pathos): Die Servicemethode sollte das zurückgeben, was dem Use Case entspricht. Wenn der Use Case „Anzahl der Positionen ermitteln“ ist, geben Sie die Anzahl der Positionen zurück. Wenn der Use Case „Bestellkopf holen“ ist, geben Sie den Bestellkopf zurück. Wenn Sie nach außen einfach die Entität zurückgeben, weil es „einfacher ist“, zahlen Sie später unweigerlich mit Komplexität: entweder durch Ausnahmen, unerwartete Abfragen oder beides.

5. Überraschende Auslöser: toString(), Logs, Debugger

Und genau hier sind dieselben zufälligen Auslöser besonders unangenehm, die zuvor schon erwähnt wurden. Solange order noch managed ist, erzeugt der Aufruf von items.size() in toString() oder beim Loggen einfach still ein SQL. Nach dem Verlassen von @Transactional versucht derselbe Aufruf, SQL ohne Session auszuführen – und dann fangen Sie die LazyInitializationException.

Das Problem ist also nicht, dass toString() „verboten“ ist oder dass Logging an sich schlecht ist. Das Problem ist, dass auch technischer Code zum ersten echten Zugriff auf eine lazy-Beziehung werden kann – nur dann, wenn das ORM sie nicht mehr laden kann.

Beim Debugger ist die Geschichte dieselbe. Die IDE versucht, den Inhalt einer Collection anzuzeigen, oder ruft toString() auf, und Sie sehen eine Ausnahme, die „aus dem Nichts“ zu kommen scheint. Tatsächlich ist die Quelle dieselbe: Zugriff auf eine lazy-Beziehung nach dem Schließen des persistence context.

6. Typische Fehler beim Arbeiten mit dem persistence context

In diesem Thema gibt es einige „klassische Fallen“, und fast alle hängen nicht mit JPA-Annotationen zusammen, sondern damit, wie wir über die Grenzen des Datenlesens denken und was wir genau aus dem Service nach außen zurückgeben. Die gute Nachricht: Diese Fehler sind leicht zu erklären und recht einfach abzustellen, wenn man sie einmal mit dem persistence context verknüpft hat.

Fehler Nr. 1: „Der Service gibt die Entity zurück, den Rest klären wir später.“
Das ist eine sehr verbreitete Angewohnheit: Der Service liest CustomerOrder und gibt sie dem aufrufenden Code zurück, und der „irgendwie“ dann einen String, ein DTO oder was auch immer zusammenbaut. Das Problem ist, dass das Zusammenbauen des Ergebnisses fast immer zu einem Zugriff auf lazy-Beziehungen führt, aber nach dem Verlassen der @Transactional-Methode ist die Entität bereits detached. Die Lösung besteht meist darin, aus dem Service das Ergebnis des Use Cases (Zahl, String, record) und nicht die Entität „wie sie ist“ zurückzugeben.

Fehler Nr. 2: Die LazyInitializationException durch Umstellung auf EAGER behandeln.
Manchmal scheint das der schnelle Weg zu sein, „damit es nicht abstürzt“. Aber der Preis ist unvorhersehbares Laden von Daten, überflüssige Abfragen und sehr schwere Lesevorgänge dort, wo man Leichtigkeit erwartet. Schlimmer noch: Eager-Beziehungen beginnen ein Eigenleben zu führen: Sie ändern eine Beziehung, dann taucht eine andere auf, und so verwandeln Sie nach und nach Ihr Modell in einen „riesigen Objektgraphen“, der sich selbst ohne Erlaubnis aus der Datenbank liest.

Fehler Nr. 3: lazy-Beziehungen in toString() und beim Loggen anzurühren.
Das ist eines der unangenehmsten Szenarien, weil die Ausnahme nicht im „Business-Code“, sondern an einer technischen Stelle auftritt: Log, Debugger, irgendein Helper. Die Lösung ist Disziplin: Der toString einer Entity sollte flach sein und keine Beziehungen anfassen. Wenn Sie „schöne Logs“ wünschen, loggen Sie die benötigten Felder explizit innerhalb der Transaktion.

Fehler Nr. 4: Nicht unterscheiden zwischen „Objekt existiert“ und „Beziehungsdaten sind bereits geladen“.
Ein Anfänger sieht order.getItems() und denkt: „Die Methode existiert, also ist da schon eine Liste.“ Bei lazy Loading ist das nicht so: Da liegt ein „Versprechen auf eine Liste“, das nur bei offenem persistence context eingelöst werden kann. Deshalb müssen Sie den Zugriff auf size(), Iteration und das Lesen verschachtelter Felder als potenziellen SQL-Zugriff betrachten, nicht als „Arbeit mit einer Collection im Speicher“.

Fehler Nr. 5: Sich zu wundern, dass @Transactional(readOnly = true) das Nachladen „erlaubt“.
Manchmal denken Leute, eine Read-Only-Transaktion sei „ganz ohne Datenbank“ oder „ohne ORM-Mechanik“. Tatsächlich bietet sie durchaus einen Kontext zum Lesen und für lazy-Initialisierung; sie drückt nur die Absicht aus, „wir planen keine Datenänderungen“. Wenn Sie also in einem Leseszenario korrekt über lazy-Beziehungen navigieren müssen, ist eine Read-Only-Transaktion eine normale und sogar wünschenswerte Form.