Klaus Schultz  Reverse- & Software-Engineering

Erfahrungswerte und Tips für Hibernate 3.2

1. Basics

Für jedes Attribut bzw. jede Collection muss man ein get-/set-Methoden-Paar spendieren. Dieses muss aber nicht unbedingt public sein, private reicht auch. Das ist gut für den Fall, wenn man aus Design-Gründen eine public-Methode mit einer anderen Signatur oder mehr Intelligenz anbieten will. Z.B. zum Zugriff auf eine Collection public nur einen Iterator anbieten will, um die Kapselung zu erhalten.

Hibernate leitet aus dem Java-Typ eines Attributs einen SQL-Typ ab. Das Default-Mapping der Typen ist hier in der Referenz beschrieben (im Buch "Java Persistence with Hibernate" ist es allerdings genauer beschrieben). Dort sollte man vor allem dann hineinschauen, um nachzulesen

Ein Attribut, das einen Geldbetrag darstellt, soll nicht den Typ Double erhalten, sondern BigDecimal (wenn nicht ein genereller Money-Typ zur Verfügung steht). Bei einem Double treten Ungenauigkeiten in den Nachkommastellen auf, die beim Vergleichen von Beträgen zu Fehlern führen.
Hibernate hat ein passendes Default-Mapping für  BigDecimal, z.B.  für Oracle NUMBER(19,2).

Jedes Entity, das durch Hibernate verwaltet wird, muss eine passende equals()- und hash()-Methode erhalten (vgl. Referenz ). Es liegt nahe, dazu den Primärschlüssel bzw. die ID zu verwenden:

@Override
public boolean equals(Object obj) {
   if (this == obj)
       return true;
   if ( obj == null)
       return false;
   if ( obj instanceof MyClazz == false)
       return false;
   MyClazz other = (MyClazz) obj;
   if ( getId() == 0 ) {
       if ( other.getId() != 0 )
          return false;
   }
   else {
      if ( getId() != other.getId() )
         return false;
   }
   return true;
}

Dabei muss beachten:

2. Performance, insbesondere im Batch

Die grundlegende Performance wird natürlich auf der Datenbank erzielt, durch den richtigen Einsatz von Indizes etc. Das ist normales Datenbank-Thema und wird hier nicht weiter erläutert. Hier geht es um Hibernate: werden performante SQL-Statements erzeugt, wie viel SQL-Statements werden erzeugt.

In der Referenzdokumentation ist dem Thema Batch ein eigenes Kapitel gewidmet, ebenso im Buch. Das wiederhole ich hier nicht, sondern kommentiere es teilweise bzw. lenke den Augenmerk auf weitere Aspekte.

2.1 alle Objekte im Hauptspeicher?

Ein Hauptproblem in der Batch-Verarbeitung (bzw. Massenverarbeitung) ist die Unmenge von Objekten, die erzeugt werden und bei naivem Programmieren zu einer out-of-memory-Exception führen (spätestens in der Produktion). Deswegen wird in der Referenzdokumentation bzw. im Buch vorgeschlagen, in regelmässigen Intervallen ein flush() und clear() durchzuführen, um die Objekte aus der Session zu entfernen, so dass sie der GC aufräumen kann (Codezitat aus der Referenzdokumentation) :

Eine Möglichkeit dafür ist, am Anfang des Batches mit einem HQL- oder Criteria-Query einen Arbeitsvorrat zu bestimmen und diesen Arbeitsvorrat dann portionsweise abzuarbeiten. Der Arbeitsvorrat kann natürlich nicht die Menge der zu bearbeitenden Objekte sein (diese würden alle instanziiert, vgl. oben: out-of-memory-Exception), sondern die Menge der IDs der zu bearbeitenden Objekte (Good Bye, Objektorientierung). Bei einem Criteria-Query erreicht man das mit einer Projection:
criteria.setProjection( Projections.id() )   vgl. Kapitel 15.1.3

2.2 Abfragen und Updates gemischt

Ein generelles Problem für Persistenz-Frameworks ist:  wenn eine Abfrage (z.B. Criteria oder HQL oder JPA-QL) gemacht wird, und im Cache des Frameworks sind geänderte Objekte, die noch nicht auf die Datenbank geschrieben wurden - wie soll die Richtigkeit des Abfrageergebnisses gewährleistet werden?

Die Antwort der Hibernate-Autoren und des JPA-Gremiums ist: falls das Abfrageergebnis durch die Objekte im Cache (der Hibernate-Session, des persistence context) beeinflusst werden könnte, wird vor dem Absetzen des SQL-Query die Datenbank mit einem automatischen flush synchronisiert.

Nach meiner Beobachtung führt Hibernate hier ein flush() durch, auch wenn die zu ändernden Tabellen garnichts mit den in der Abfrage berührten Tabellen zu tun haben. Das mag generell OK sein wegen undurchschaubarer Fernwirkungen, aber bremst einen Batchlauf gehörig aus.

Deswegen

2.3 Abfragebeschleunigung durch Batch_Fetch_Size und JOIN FETCH

Nehmen wir folgenden Ausschnitt aus einem Modell und eine Abfrage darauf, die Angestellte einschliesslich ihrer Job-Bezeichnung anlistet.

Hibernate muss dazu die jeweiligen Job-Objekte lesen und instanziieren. Die Einstellung default_batch_fetch_size   beeinflusst, wie effektiv das passiert. Wird default_batch_fetch_size nicht gesetzt, holt Hibernate, nachdem es die Tabelle Employee abgefragt hat, das Job-Objekt zu jedem Angestellten einzeln (sofern noch nicht in der Session vorhanden):

Wird default_batch_fetch_size z.B. auf 10 gesetzt, holt Hibernate auf einen Rutsch 10 Job-Objekte:

Die Einstellung wirkt übrigens auch im JPA-Modus - in der persistence.xml  ist einfach ein Hibernate-spezifischer Eintrag enthalten:
<property name="hibernate.default_batch_fetch_size"  value="10"/>

Die Assoziation vom Entity Angestellter zum Entity Job ist, wie üblich, mit lazy loading definiert.
@ManyToOne(optional=false , fetch=FetchType.LAZY)
Die Verwendung von FetchType.EAGER verändert die Anzahl SQL-Statements nicht, also bleiben wir bei lazy loading.

Das Optimale für diese Liste von Angestellten ist natürlich, wenn die Jobs mit dem gleichen SQL wie die Angestellten gelesen werden. Das geschieht (sowohl in HQL als auch JPA-QL) mit dem Schlüsselwort JOIN FETCH:
createQuery("select ang from Angestellter ang left join fetch ang.job " )

Während  default_batch_fetch_size eine generelle Einstellung ist, wird hier der Query optimiert, so dass die Job-Objekte eager geladen werden.