Warum hat Hibernate meine Datenbank aktualisiert?

Hibernate ist ein hochentwickeltes ORM-Framework, das den Zustand Ihrer persistenten Daten für Sie verwaltet. Die wichtige, aber schwierige Aufgabe der Verwaltung des persistenten Zustands Ihrer Anwendung an ein Framework zu übergeben, hat zahlreiche Vorteile. Einer der Nachteile ist jedoch, dass Sie gewissermaßen die Kontrolle darüber verlieren, was wo und wann passiert. Ein Beispiel dafür ist die Funktion Dirty Checking, die Hibernate bietet. Mit der Dirty Checking-Funktion ermittelt Hibernate, welche Daten in Ihrer Datenbank aktualisiert werden müssen. In vielen Fällen ist diese Funktion sehr nützlich und funktioniert ohne Probleme, aber manchmal kann es vorkommen, dass Hibernate etwas aktualisiert, was Sie nicht erwartet haben. Herauszufinden, warum das passiert ist, kann eine ziemlich schwierige Aufgabe sein. Ich wurde neulich gebeten, ein Problem mit einer StaleObjectState-Ausnahme zu untersuchen. StaleObjectState-Ausnahmen werden von Hibernate verwendet, um einen optimistischen Sperrkonflikt zu signalisieren: Während ein Benutzer (oder Prozess) versucht, ein Datenelement zu speichern, wurde dasselbe Datenelement in der zugrunde liegenden Datenbank seit dem letzten Lesen bereits geändert. Das Problem war nun, dass der Prozess, der die Ausnahme auslöste, der einzige Prozess war, der diese Daten ändern sollte. Aus funktionaler Sicht kann es keinen anderen Benutzer oder Prozess gegeben haben, der die Daten in der Zwischenzeit geändert hat. Was war also los? Als wir einige Zeit im Protokoll herumstöberten, fanden wir heraus, dass die Daten von einem anderen Prozess aktualisiert wurden, der diese Daten eigentlich nur lesen sollte. Irgendwie beschloss Hibernate, dass die von diesem Prozess gelesenen Daten schmutzig geworden waren und gespeichert werden sollten. Jetzt musste er also herausfinden, warum Hibernate diese Daten für schmutzig hielt. Hibernate kann an mehreren Stellen in einer Anwendung eine Schmutzprüfung durchführen:

1. Wenn eine Transaktion übertragen oder eine Sitzung geleert wird, denn zu diesem Zeitpunkt sollten die in der Transaktion oder Sitzung vorgenommenen Änderungen in der Datenbank gespeichert werden.
2. Wenn eine Abfrage ausgeführt wird. Um zu verhindern, dass Änderungen, die sich noch im Speicher befinden, übersehen werden, flusht Hibernate Daten, die abgefragt werden könnten, kurz vor der Ausführung der Abfrage in die Datenbank. Dabei versucht Hibernate, wählerisch zu sein und nicht immer alles zu flushen, sondern nur die Daten, die abgefragt werden könnten.

Es ist ziemlich schwierig, all diese Stellen zu überprüfen, um herauszufinden, wo die Daten als schmutzig eingestuft werden, vor allem, wenn der Prozess mehrere Abfragen ausführt. Um herauszufinden, warum Hibernate die Daten als schmutzig einstuft, müssen wir in die Hibernate-Interna eindringen und mit der Fehlersuche im Code des Frameworks beginnen. Die Architektur von Hibernate ist recht komplex. Es gibt eine Reihe von Klassen, die an der Dirty-Prüfung und der Aktualisierung von Entitäten beteiligt sind:

• Der DefaultFlushEntityEventListener bestimmt, welche Felder verschmutzt sind. Die Interna dieser Klasse arbeiten mit der Liste der Eigenschaften einer Entität und zwei Listen von Werten: die Werte, wie sie aus der Datenbank geladen wurden, und die Werte, wie sie derzeit in der Sitzung bekannt sind. Sie delegiert die Ermittlung der 'Verschmutzung' eines Feldes an den registrierten Abfangjäger und an die Typen der Eigenschaften.
• Die EntityUpdateAction ist für die Aktualisierung selbst verantwortlich. Ein Objekt dieses Typs wird zu einer ActionQueue hinzugefügt, die ausgeführt wird, wenn eine Sitzung geleert wird.

Diese Klassen zeigen einige der Muster, die in den Interna von Hibernate verwendet werden: Eventing und Action Queuing. Diese Muster machen die Architektur des Frameworks sehr klar, aber sie machen es manchmal auch sehr schwer, den Vorgängen zu folgen... Wie bereits erklärt, kommt das Flushing recht häufig vor und das Setzen eines Haltepunkts im DefaultFlushEntityEventListener ist in der Regel keine gute Idee, da er sehr oft getroffen wird. Eine EntityUpdateAction wird jedoch nur erstellt, wenn eine Aktualisierung an die zugrunde liegende Datenbank ausgegeben wird. Um herauszufinden, was das Problem war, setzte ich einen Haltepunkt im Konstruktor und ging von dort aus zurück. Es stellte sich heraus, dass Hibernate den schmutzigen Zustand des Objekts nicht feststellen konnte und daher beschloss, die Entität sicherheitshalber zu aktualisieren. Wie bereits erwähnt, verwendet Hibernate den "geladenen Zustand", um festzustellen, ob ein Objekt schmutzig ist. Dies ist der Zustand des Objekts (die Werte seiner Eigenschaften), wenn es aus der Datenbank geladen wird. Hibernate speichert diese Information in seinem Persistenzkontext. Bei der Dirty-Prüfung vergleicht Hibernate diese Werte mit den aktuellen Werten. Wenn der "geladene Zustand" nicht verfügbar ist, kann Hibernate die Dirty-Prüfung nicht durchführen und stuft das Objekt als Dirty ein. Das einzige Szenario, in dem der geladene Zustand nicht verfügbar ist, ist jedoch, wenn das Objekt wieder an die Sitzung angehängt und somit nicht aus der Datenbank geladen wurde. Der Prozess, den ich untersucht habe, funktioniert jedoch nicht mit losgelösten Daten. Es gibt noch ein weiteres Szenario, in dem Hibernate den "geladenen Zustand" der Daten verliert: Wenn die Sitzung geleert wird. Dieser Vorgang verwirft den gesamten Zustand im Persistenzkontext vollständig. Es handelt sich hierbei um eine recht gefährliche Operation, die Sie in Ihrem Anwendungscode verwenden sollten und die Sie nur aufrufen sollten, wenn Sie sich sehr sicher sind, was Sie tun. In unserem Fall wurde die Sitzung irgendwann geleert und gelöscht, was zu den unerwünschten Aktualisierungen und schließlich zu den StaleObjectStateExceptions führte. In der Tat eine unerwünschte Situation. Nachdem wir die Löschung entfernt hatten, waren die Aktualisierungen verschwunden und der Fehler war behoben. Die Verwendung von Hibernate kann einem Entwickler viel Zeit ersparen, wenn die Dinge reibungslos laufen. Wenn ein Problem auftritt, ist oft viel spezielles Hibernate-Wissen und eine beträchtliche Menge an Zeit erforderlich, um es zu diagnostizieren und zu lösen.