Archiv für die Kategorie ‘Spring-Framework’

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 {}