9.2. Behobene Probleme mit Hibernate

Die Verwendung einer session.createSQLQuery führte zu einem Speicherleck, da die equals- und hashCode-Methoden in NativeSQLQuerySpecification nicht ordnungsgemäß implementiert waren und die gleichzeitige Verwendung von LRUMap dazu führte, dass die Map die Maximalgröße überschritt. Diese Probleme wurden behoben, und es kommt nicht mehr zu einem Speicherleck.

Die Änderungen für JBPAPP-4471 führten zu einem Problem wenn Nutzer nicht-JDK serialisierbare Klassen mit SerializableType mappten und versuchten, diese Werte in einem Cache der zweiten Ebene zu cachen. SerializableType meldete den Klassenlader von java.io.Serializable als den für die Deserialisierung zu verwendenden Klassenlader. Jedoch konnte dieser Klassenlader nicht in den Klassenlader oder nicht-JDK Klassen sehen.

Der Klassenlader aus org.hibernate.util.SerializationHelper.deserialize(InputStream, ClassLoader) versucht jetzt, den zu deserialisierenden Klassenlader aufzulösen. Ist dies nicht erfolgreich möglich, verwendet es den Kontextklassenlader aus dem aktuellen Thread und den Klassenlader, der die Hibernate-Klasse lädt.

Das Query Cache erforderte, dass die Session oder der Entity Manager geschlossen und erneut geöffnet wurden, ehe es wirksam wurde, da Hibernate den Zeitstempel einer gecachten Anfrage mit dem Zeitstempel der aktuellen Session vergleicht, wenn es eine Anfrage vom Cache abruft. Dies wurde jetzt behoben und Hibernate verwendet nextTimestamp() zum Abruf des aktuellen Zeitstempels statt den gecachten Zeitstempel.

@CollectionId beschreibt eine Bezeichnerspalte für eine Bag (z.B. eine idbag). nullable sollte explizit auf "false" gesetzt werden. Dies wurde behoben und nullable ist jetzt standardmäßig auf false eingestellt.

PostgreSQL ließ SchemaExport nicht fallen, wenn Einschränkungsnamen sich änderten. Hibernate gibt jetzt eine Kaskade heraus, wenn es versucht eine Tabelle fallen zu lassen, wodurch das Problem gelöst wird.

Hibernate verwendet StandardDialectResolver, um den Hibernate Dialekt zu erraten, wenn die hibernate.dialect-Property nicht in der Hibernate Properties-Datei aufgefunden wird, hibernate.cfg.xml oder persistence.xml. StandardDialectResolver gab SybaseDialect wieder, wenn der Datenbankname, den es aus den Datenbank-Metadaten extrahierte Sybase SQL Server oder Adaptive Server Enterprise ist. Da aber SybaseDialect veraltet ist, führte dies zu Problemen. Der StandardDialectResolver errät jetzt den korrekten zu verwendenden Dialekt, wenn hibernate.dialect nicht konfiguriert ist.

Beim Scrollen einer HQL-Anfrage mit Join Fetch an einer Collection bewegte sich FetchingScrollableResultsImpl.last() nicht zum letzten Ergebnis, wenn der Cursor sich hinter dem letzten Ergebnis befand. Stattdessen blieb der Cursor in der Position hinter dem letzten Ergebnis. Dies konnte zu org.hibernate.exception.GenericJDBCException: could not perform sequential read of results führen. Die Lösung für dieses Problem stellt nun sicher, dass der Cursor sich wie erwartet zum letzten Ergebnis bewegt.

War eine Spalte in Backticks (`) definiert, so schlugen @JoinTable und @JoinColumn Mappings mit AnnotationException fehl, wenn der Spaltenname mit Backticks referenziert wurde. Hibernate vergleicht jetzt den referencedColumnName mit dem in Anführungszeichen gesetzen Namen statt mit dem Tabellenspaltennamen.

getColumnSpan gab 0 wieder, wenn Entities mit OneToOne-Mappings verglichen wurden, selbst wenn dieselbe Entity verglichen wurde, was zu TypeMismatchExceptions führte. Der Algorithmus von getColumnSpan wurde geändert, so dass die Spaltenanzahl anhand des Bezeichners oder des eindeutigen Schlüsseltyps identifiziert werden kann.

LikeExpression handhabte das ignoreCase-Flag nicht ordnungsgemäß, wenn ignoreCase auf "false" gesetzt war. Die korrekte SQL property like ? wurde erstellt, aber das Flag in getTypedValues wurde nicht verwendet, und es wurde stets ein Wert in Kleinbuchstaben produziert. Dieses Problem wurde behoben und Kleinbuchstaben oder der Originalfall werden verwendet, wenn ignoreCase auf "false" gesetzt ist.

In einer stateless Session laden Anfragen Objekte in einem zweiphasigen Vorgang: In der ersten Phase wird ein temporärer Persistenzkontext mit leeren Objekten bevölkert. In der zweiten Phase werden die Mitgliedsdaten der Objekte aus der Datenbank gelesen. Enthält ein Objekt eine Assoziation oder eine Collection, so führt die Anfrage einen rekursiven Aufruf an die get()-Methode der Session durch. Dies bereinigt den temporären Persistenzkontext.

Enthielt das übergeordnete Objekt andere Assoziationen, die als Teil der zweiten Phase gelesen werden sollten, so meldete Hibernate eine Ausnahme, da die Assoziationen nicht im Persistenzkontext gefunden werden konnten.

Dies wurde mittels einer neuen Methode behoben: org.hibernate.engine.PersistenceContext.isLoadFinished(). Diese Methode teilt StatelessSession mit, wann ein temporärer Persistenzkontext bereinigt werden soll.

Ein Fehler im org.hibernate.cfg.OneToOneSecondPass-Code führte manchmal zu einer org.hibernate.PropertyValueException wenn ein One-to-One Mapping verarbeitet wurde. Die Ausnahme erfolgte deshalb, weil wenn JOINs otherSideProperty, otherSideJoin alte Daten enthielten statt dass sie Null waren. Der org.hibernate.cfg.OneToOneSecondPass-Code wurde korrigiert.

Hibernate generierte in einigen Situationen den falschen Alias in der Table-pre-class Vererbungsstrategie. (Beispiele finden Sie in der JIRA.) AbstractCollectionPersister verwendet jetzt Schlüsselspaltenaliasse, die von Column.getAlias(Dialect,Table) generiert werden, so dass das Table-pre-class Vererbungsstrategie-Mapping korrekt ist.

Konnte ein Cache-Provider nicht gefunden werden, so wurde ein NoClassDefFoundError gemeldet, der folgende Nachricht enthielt:

net/sf/ehcache/CacheException

net/sf/ehcache/CacheException

Konnte ein Connection-Provider nicht gefunden werden, so wurde eine HibernateException mit folgender Nachricht gemeldet:

Could not instantiate connection provider: " + providerClass

Could not instantiate connection provider: " + providerClass

Es erfolgen jetzt informativere Nachrichten, wenn diese Fehler auftreten.

Die Iterationsreihenfolge von HashMaps und HashSets für JDK 6 verursacht unterschiedliche Spaltenreihenfolgen in Union-Klauseln oder Union-Unterklassen abhängig davon, ob JDK 5 oder 6 verwendet wird. Da die Abweichung der Spaltenreihenfolgen über die Union-Klauseln hinweg konsistent ist, sind die daraus folgenden Abfragen gültig, allerdings kann diese Veränderung möglicherweise die Leistung beeinträchtigen. Die Implementierung von HashSet wurde für die identische Performance zwischen den verschiedenen JDKs zu LinkedHashSet geändert.

Hibernate konnte in der Vergangenheit unter JDK 6 nicht kompiliert werden, weil die folgenden Klassen JDK 6 Interfaces nicht vollständig implementierten:

Es kam zu einem NoSuchMethodError wenn eine Applikation eine Methode erforderte, die in diesen Klassen fehlte. Die fehlenden Methoden wurden nun implementiert, so dass dieser Fehler nicht mehr auftritt.