Mit ‘Java’ getaggte Artikel

Pitfall Exceptions bei annotierten Spring-Transaktionen

Donnerstag, 02. September 2010

Spring ist eines der beliebtesten – wenn nicht das beliebteste – Framework in der Java-Welt. Es bietet für nahezu jede vorstellbare Komponente/Facette bei der Anwendungsentwicklung Unterstützung und hilft von weiteren verwendeten Frameworks (z.B. Web-Frameworks) zu abstrahieren. Eine Paarung die man häufig in Java-Projekten zur Realisierung der Persisterung findet, ist Spring in Kombination mit Hibernate.

Spring hilft hier die Integration von Hibernate in die Anwendung zu vereinfachen und spielt vor allem beim Transaktions-Management eine wichtige Rolle. Egal ob nun Services oder DAOs, Spring erlaubt es einfach per Annotations die Transaktionen zu deklarieren und zu steuern. Dafür genügt – bei entsprechender Konfiguration – eine @Transactional Annotation an einem Method-Body:

@Transactional
public void doInTransaction() {
    writeSomething1();
    writeSomething2();
}

Die so deklarierte Methode lässt writeSomething1() und writeSomething2() in einer Transaktion ablaufen. Schlägt writeSomething2() fehl, so wird writeSomething1() zurückgerollt. Möchte man nun Auskunft über den Erfolg der Methode bzw. über gewisse, aufgetretene Fehler geben, gibt es mehrere Möglichkeiten. Die erste ist der eher veraltete, aber noch immer anzutreffende Status-Code. Hier wird zumeist ein Integer-Wert benutzt, um bestimmte Ereignisse (Erfolg, Fehler1, Fehler2 …) abzubilden. Für unser obiges Beispiel könnte dass dann etwa so ausschauen (reduziert auf einen Fehler- und Erfolgsfall):

@Transactional
public int doInTransaction() {
  try {
    writeSomething1();
    writeSomething2();    
  } catch (WriteSomething2Exception) {
      return 1:
  }
  return 0;
}
 
class WriteSomething2Exception extends Exception {}

Das problematische an dieser Implementierung ist, dass sie das Transaktionsmanagement aushebelt. Denn wirft writeSomething2() die Exception, wird sie nicht weitergeleitet und so kann Spring auch nicht erkennen, dass ein Fehler vorliegt und die Transaktion zurückgerollt werden muss.

Statt die Fehler mit Status-Codes abzubilden, kann man natürlich auch Exceptions für die Fehlerfälle verwenden:

@Transactional
public int doInTransaction() throws WriteSomething2Exception {
  writeSomething1();
  writeSomething2();    
}
 
class WriteSomething2Exception extends Exception {}

In diesem Fall wird die Exception weitergeleitet und alles sollte klappen. Sollte man mindestens meinen… Aber der obige Code hat noch immer den gleichen Effekt. Warum? Nun, um das herauszufinden muss man lediglich das java-doc der @Transactional Annotation genau lesen:

/**
 * Describes transaction attributes on a method or class.
 *
 * <p>This annotation type is generally directly comparable to Spring's
 * {@link org.springframework.transaction.interceptor.RuleBasedTransactionAttribute}
 * class, and in fact {@link AnnotationTransactionAttributeSource} will directly
 * convert the data to the latter class, so that Spring's transaction support code
 * does not have to know about annotations. If no rules are relevant to the exception,
 * it will be treated like
 * {@link org.springframework.transaction.interceptor.DefaultTransactionAttribute}
 * (rolling back on runtime exceptions).
 * 
 * @author Colin Sampaleanu
 * @author Juergen Hoeller
 * @since 1.2
 * @see org.springframework.transaction.interceptor.DefaultTransactionAttribute
 * @see org.springframework.transaction.interceptor.RuleBasedTransactionAttribute
 */
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {
...
}

Und siehe da, die letzte Zeile im Kommentar enthält die Lösung. Spring rollt lediglich bei RuntimeExceptions zurück! Da unsere Exception jedoch eine checked Exception ist, passiert nichts. Die Lösung ist also nur RuntimeExceptions zu verwenden. Was aber, wenn wir das nicht wollen? Für diesen Fall bietet die Annotation uns das Attribut rollbackFor. Dort kann man dann als Wert die Klassen der Exceptions angeben kann, für die ein Rollback erfolgen soll. Für unser Beispiel sieht die Lösung dann wie folgt aus:

@Transactional(rollbackFor = WriteSomething2Exception.class)
public int doInTransaction() throws WriteSomething2Exception {
  writeSomething1();
  writeSomething2();    
}
 
class WriteSomething2Exception extends Exception {}

Christian Schätzlein


Hibernate, HashCode und Sets

Montag, 29. März 2010

Verwendet man Hibernate in seinem Projekt als O/R-Mapper, zählt es zu einer der ersten Aufaben eine adäquate Implementierung von equals und hashCode für die Entitäten bereitzustellen. Eine verbreitete Möglichkeit für die HashCode-Methode ist dabei die folgende:

    @Override
    public int hashCode() {
        return getId();
    }

Dabei liefert getId() die durch Hibernate generierte Id der Entität, sprich den PrimaryKey des Datenbank-Eintrages. Soweit verständlich. Allerdings bricht diese Implementation mit der ersten Anforderung des Hash-Code Contracts (Javadoc Auszug):

   /**
     * Returns a hash code value for the object. This method is 
     * supported for the benefit of hashtables such as those provided by 
     * <code>java.util.Hashtable</code>. 
     * <p>
     * The general contract of <code>hashCode</code> is: 
     * <ul>
     * <li>Whenever it is invoked on the same object more than once during 
     *     an execution of a Java application, the <tt>hashCode</tt> method 
     *     must consistently return the same integer, provided no information 
     *     used in <tt>equals</tt> comparisons on the object is modified.
     *     This integer need not remain consistent from one execution of an
     *     application to another execution of the same application. 
     * <li>If two objects are equal according to the <tt>equals(Object)</tt>
     *     method, then calling the <code>hashCode</code> method on each of 
     *     the two objects must produce the same integer result. 
     * <li>It is <em>not</em> required that if two objects are unequal 
     *     according to the {@link java.lang.Object#equals(java.lang.Object)} 
     *     method, then calling the <tt>hashCode</tt> method on each of the 
     *     two objects must produce distinct integer results.  However, the 
     *     programmer should be aware that producing distinct integer results 
     *     for unequal objects may improve the performance of hashtables.
     * </ul>
     * <p>
     * As much as is reasonably practical, the hashCode method defined by 
     * class <tt>Object</tt> does return distinct integers for distinct 
     * objects. (This is typically implemented by converting the internal 
     * address of the object into an integer, but this implementation 
     * technique is not required by the 
     * Java<font size="-2"><sup>TM</sup></font> programming language.)
     *
     * @return  a hash code value for this object.
     * @see     java.lang.Object#equals(java.lang.Object)
     * @see     java.util.Hashtable
     */

Da Hibernate die Id erst erzeugt, wenn die Entität gespeichert wird, verändert sich der Hash-Code während des Lebenszykluses des Objektes. In vielen Fällen stellt das kein Problem da. Arbeitet man allerdings mit HashSets als Collection für eine Assoziation und verwendet gleichzeitig Speicher-Kaskaden, führt diese Implementierung zu Schwierigkeiten. Beispiel:

@Entity
public class FunkyVO extents BaseVO {
 
    @OneToMany(mappedBy = "funky", fetch = FetchType.LAZY)
    @Cascade({ org.hibernate.annotations.CascadeType.ALL})
    private final Set<GrooveVO> grooves= new HashSet<GrooveVO>();
 
}

Und dazu folgender Pseudocode:

FunkyVO funkyVO = new FunkyVO();
GrooveVO grooveVO = new GrooveVO();
funkyVO.getGrooves().add(grooveVO);
PersistService.persist(funkyVO);
funkyVO.getGrooves().contains(grooveVO); // => false
funkyVO.getGrooves().remove(grooveVO); // => false
funkyVO.getGrooves().add(grooveVO); // => false

Da die Id erst durch das Persistieren erzeugt wird, ändert sich der Hash-Code nachdem das Objekt zur Liste hinzugefügt wurde. Die Konsequenz ist, dass das Objekt nun nicht mehr wiedergefunden wird (contains), nicht mehr entfernt werden kann (remove) und bei einem erneuten Hinzufügen auch nicht als Duplikat erkannt wird (add).

Und wie sieht die Lösung aus?

Eine Möglichkeit wäre, im ganzen Projekt darauf zu achten, dass die Entitäten erst nach dem Speichern den Listen hinzugefügt werden…

Hibernate verweist dagegen bei diesem Problem darauf, dass die generierte Id nicht in equals oder hashCode verwendet werden soll. Als Lösung wird dort ein expliziter BusinessKey vorgeschlagen, der nichts mit dem PrimaryKey zu tun hat und somit auch beim Erzeugen der Entität angelegt werden könnte.

Möchte man weiterhin den PrimaryKey benutzen, kann man alternativ auch die Id selbst generieren. Allerdings muss man Hibernate dann beibringen, anhand eines anderen Attributes zu entscheiden, ob die Entität neu ist und ein INSERT ausgeführt werden muss oder ob lediglich ein UPDATE nötig ist. Ein solches Attribut könnte das Version Attribut – welches beim OptimisticLocking verwendet wird – oder etwa ein CreatedAt Feld sein, dass beim Insert durch die Datenbank gefüllt wird.


Christian Schätzlein


Datum in Hibernate: Der Wolf(Timestamp) im Schafspelz(Date)

Freitag, 22. Januar 2010

Benutzt man Hibernate als OR-Mapper und will ein java.util.Date (Datum und Uhrzeit) speichern, ist Vorsicht geboten. Da java.sql.Timestamp von java.util.Date erbt, und der Typ in der Datenbank i.d.R. timestamp ist, bekommt man von Hibernate gegebenenfalls ein Timestamp-Objekt, und nicht ein Date-Objekt. Eigentlich kein Problem, doch die Klasse Timestamp ist …kaputt! Auszug aus dem Javadoc von Timestamp:

The Timestamp.equals(Object) method never returns true when passed a value of type java.util.Date because the nanos component of a date is unknown.

Will man zwei Dates vergleichen und befindet sich hinter der ersten Referenz ein Timestamp-Objekt, schlägt equals fehl.

Date d = new Date();
Date ts = new Timestamp(d.getTime());
System.out.println(ts.equals(d));    //returns false

Wie soll ich also zwei Dates miteinander vergleichen? Es wird noch schlimmer:

System.out.println(ts.compareTo(d)); // return 0
System.out.println(d.compareTo(ts)); // returns 1

Auch die compareTo-Methode ist fehlerhaft liefert ein anderes Ergebnis als erwartet. Schaut man sich den Konstruktor von Timstamp an, kommt man aus dem Staunen Entsetzen nicht mehr heraus. Die Klasse Date speichert das Datum millisekundengenau in dem Feld fastTime. Die Klasse Timestamp hingegen speichert das Datum sekundengenau in dem Feld fastTime und die Milli- und Nanosekunden im Feld nanos. Warum dies so ist, und nicht nur die Nanosekunden im Feld nanos gespeichert werden, ist mir ein Rätsel.

Will man nun ein Date und einen Timestamp miteinander vergleichen (z.B. auch mit before() und after()) schlägt dies fehl. Die compareTo-Methode von Date vergleicht die Millisekunden aus dem Feld fastTime, beim Timestamp-Objekt ist dies nur sekundengenau, die Millisekunden sind im Feld nanos gespeichert, und werden nicht berücksichtigt.

Dieses Problem tritt häufig in Verbindung mit Hibernate auf, die Schuld liegt aber bei der Standard Java-API. Allerdings lässt sich das Problem umgehen, indem man Hierbernate mit einem UserType zwingt, nur Objekte vom Typ Date zu liefern.

public class DateTimeType implements UserType {
    private static final int[] SQL_TYPES = new int[] {Types.TIMESTAMP};
    public DateTimeType() {
        super();
    }
 
    @SuppressWarnings("unchecked")
    public Class returnedClass() {
        return java.util.Date.class;
    }
 
    public int[] sqlTypes() {
        return SQL_TYPES;
    }
 
    public boolean equals(final Object x, final Object y) {
        if (x == y) {
            return true;
        }
        if (x == null || y == null) {
            return false;
        }
        Date xDate = (Date) x;
        Date yDate = (Date) y;
        return xDate.equals(yDate);
    }
 
    public Object nullSafeGet(final ResultSet rs, final String[] names, final Object owner) throws SQLException {
        // extract Timestamp from the result set
        Timestamp timestamp = (Timestamp) Hibernate.TIMESTAMP.nullSafeGet(rs, names[0]);
        // return the value as a java.util.Date (dropping the nanoseconds)
        if (timestamp == null) {
            return null;
        } else {
            return new Date(timestamp.getTime());
        }
    }
 
    public void nullSafeSet(final PreparedStatement st, final Object value, final int index) throws SQLException {
        // handle the NULL special case immediately
        if (value == null) {
            st.setTimestamp(index, null);
            return;
        }
        // make sure the received value is of the right type
        if (!Date.class.isAssignableFrom(value.getClass())) {
            throw new IllegalArgumentException("Received value is not a [java.util.Date] but [" + value.getClass() + "]");
        }
        // set the value into the resultset
        Timestamp tstamp = null;
        if (value instanceof Timestamp) {
            tstamp = (Timestamp) value;
        } else {
            tstamp = new Timestamp(((Date) value).getTime());
        }
        st.setTimestamp(index, tstamp);
    }
 
    public Object deepCopy(final Object value) {
        if (value == null) {
            return null;
        } else {
            return ((Date) value).clone();
        }
    }
 
    public boolean isMutable() {
        return true;
    }
 
    @Override
    public Object assemble(final Serializable cached, final Object owner) {
        return deepCopy(cached);
    }
 
    @Override
    public Serializable disassemble(final Object value) {
        return (Date) value;
    }
 
    @Override
    public int hashCode(final Object x) {
        return x.hashCode();
    }
 
    @Override
    public Object replace(final Object original, final Object target, final Object owner) {
        return deepCopy(original);
    }
}

Möglich ist eine Konfiguration auf Packet-Ebene, indem man eine package-info.java erstellt. Folgend die Konfiguration mit Annotationen auf Klassenebene:

@TypeDefs( {@TypeDef(name = "dateTimeType", typeClass = DateTimeType.class)})
public class MyBusinessObject {
 
    @Type(type = "dateTimeType")
    @Column(name = "time")
    private Date time;
    ...
}

Eventuell wird die freie Joda Time API in Java 1.7 die alten Datum und Kalendarklassen ersetzten. Bis dahin kann man mit diesem UserType sicher sein, dass Hibernate nur Date-Objekte zur Verfügung stellt, und somit kann man wieder equals und compareTo ohne Bedenken verwenden.
Siehe auch


Jan Kuenstler


Ich weiß nicht, ob ihr schon wusstet…

Freitag, 11. Dezember 2009

aber ich bin neulich über eine Sache gestolpert, die mir so nicht bewusst war:

Was passiert wohl beim Ausführen des folgenden Java-Codes?

List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
List<Integer> list2 = Arrays.asList(8, 9, 10);
 
list.remove(0);
list.add(2);
list.addAll(list2);

Na wisst ihr es? Man bekommt eine UnsupportedOperationException. Und zwar für jede der list manipulierenden Methoden. Seltsam oder vielleicht doch nicht? Ich für meinen Teil war überrascht. Und auch die Java-Doc für Arrays.asList half mir auf dem ersten Blick nicht sofort weiter:

    /**
     * Returns a fixed-size list backed by the specified array.  (Changes to
     * the returned list "write through" to the array.)  This method acts
     * as bridge between array-based and collection-based APIs, in
     * combination with {@link Collection#toArray}.  The returned list is
     * serializable and implements {@link RandomAccess}.
     *
     * This method also provides a convenient way to create a fixed-size
     * list initialized to contain several elements:
     * 
     *     List<String>; stooges = Arrays.asList("Larry", "Moe", "Curly");
     * 
     *
     * @param a the array by which the list will be backed
     * @return a list view of the specified array
     */
    public static <T> List<T> asList(T... a) {...}

Doch beim genaueren Hinsehen bzw. Überlegen wird es klarer: fixed-size list, a list view of the specified array sowie der Methodenname asList sagen aus, dass es sich nur um eine Ansicht des Arrays bzw. der Eingaben handelt. Die Arrays-Klasse benutzt nämlich unter der Haube die eigene Implementierung java.utils.Arrays.ArrayList und diese implementiert weder add noch remove aus dem List-Interface. Hmm… Irgendwie schon blöd, denn es gibt weder Arrays.toList, noch bietet etwa die konkrete Implementierung ArrayList den komfortablen Var-Args Parameter im Konstruktor. Zudem hätte ich mir eine eindeutigere Dokumentation gewünscht, die ausdrücklich darauf hinweist, dass das Hinzufügen bzw. Entfernen nicht möglich ist.

Möchte man nun trotzdem nicht auf den syntaktischen Zucker verzichten, hilft ein kleiner – zugegebenermasen unperformanter – Workaround:

List<Integer> list = new ArrayList<Integer>(Arrays.asList(1, 2, 3, 4, 5));

Und, habt ihr es gewusst?


Christian Schätzlein