WJAX: Jürgen Höller: Leichtgewichtige Transaktionen Transaktions-Management ist mit Mythen belegt - so zum Beispiel, dass man eigentlich immer XA benötigt und Two Phase Commit. Das ist natürlich nicht der Fall, wenn man nur eine Ressource hat. Ebenfalls ist es nicht notwendig, eine O/R-Mapper-Integration über XA zu integrieren. Ebenfalls ist nicht unbedingt notwendig, bei der Integration von JMS und JDBC XA-Transaktionen zu verwenden. Und natürlich muss man nicht EJB verwenden, um Transaktions-Attribute deklarativ zu verteilen. Ebenfalls ist es nicht notwendig, Transaktionen nur in einem Application Server funktionieren. Selbst die Weitergabe des Transaktions-Kontext bei verteilten Aufrufen ist eine Sache der RMI-Implementierung und des Transaction-Managers - EJB muss nicht unbedingt involviert sein. Dabei geht es wirklich um Transaktione verschiedener Server - nicht nur die Nutzung mehrerer Ressourcen auf einem Server.

Wann soll man JTA-Transaktionen und wann native Transaktionen verwenden? Transaktions-Demarkation ist unabhängig davon - irgendwie muss das im Code ausgedrückt werden. Klassisch in XML, Annotationen oder im Code. EJB bietet solche Features - Spring natürlich auch. Dabei kann man nicht nur die Propagation einstellen, sondern auch die Isolation oder ob die Transaktion Read-Only ist sowie einen Timeout. Read-Only ist eine Optimierung, die bei einem O/R-Mapper die Überprüfung auf Änderungen an den Objekten abschaltet. Die Propagation regelt, wann eine neue Transaktion gestartet werden soll. Diese Verhaltens-Regeln sind unabhängig vom Transaction-Manager. Allerdings können nur wenige Infrastrukturen geschachtelte Transaktionen unterstützen. Das kann zum Beispiel ein Vorteil sein, wenn man sehr viele INSERTs macht und nicht alle Zurück-Rollen will, wenn irgendwo ein Fehler auftritt. Analog Möglichkeiten bieten JDBC-Treiber, die dann zum Beispiel bei einem Master-Slave-Cluster optimieren können.

Zum Setzen solcher Optionen bietet es sich an, in einer XML-Konfiguration die Transaktionen anhand von Namens-Konventionen zu definieren.

Letztendlich wird dann durch die Wahl des richtigen Transaction-Managers definiert, wie die konfigurierten Transaktionen wirklich umgesetzt werden. Und hier kommt man oft um XA herum. Aber warum nicht einfach XA verwenden? Ein Grund ist, dass XA nicht in allen Umgebungen zur Verfügung steht. Man benötigt nicht nur einen passenden Koordinator, sondern auch XA-fähige Ressourcen. Und außerdem fügt XA zur Laufzeit einen Overhead in das System ein. Der ist nicht gering, weil es komplex ist, die Garantien des XA-Protokolls tatsächlich umzusetzen. Ein Problem ist, dass der Koordinator immer dazu in der Lage sein muss, nach einem Absturz wieder aufzusetzen. Das muss in eine Datei gespeichert werden, was eben ein echter Overhead ist. Alternativ kann man eine nativen Transaction-Manager verwenden, wie es ihn in Spring für JDBC, Hibernate, JPA, JDO und JMS gibt. Dazu reicht ein einfacher Treiber - man benötigt kein XA oder ähnliches. Aber das geht nur, wenn es nur eine Ressource gibt. Der DataSourceTransactionManager bespielsweise kann native JDBC-Transaktionen unterstützen einschließlich des Isolations-Levels und verschachtelter Transaktionen. Dazu benötigt man nur einen normale JDBC-DataSource.

Mit diesen nativen Transaktionen kommt man sehr weit - es ist weit mehr als eine letzte Möglichkeit, wenn es nichts anderes gibt. Man kann die volle Mächtigkeit der Transaktionen aus der Datenbank verwenden und es ist leicht, das System aufzusetzen. Und man kann ihn auch in einer Java-EE-Umgebung verwenden - sogar mit Java-EE-DataSources. JTA ist natürlich auch eine Option - wenn man es benötigt. Der Code bleibt davon bei Spring unbeeinflusst. Es ist also nur eine Entscheidung, die man beim Deployment und der Konfiguration treffen muss.
Oder man verwendet einen integrierten Transaktions-Manager wie zum Beispiel ObjectWeb JOTM mit XAPool, der Geronimo Transaction Manager oder Atomikos, der mittlerweile Open Source ist. Dadurch kann man XA-Transaktionen auch auf einem Tomcat-Web-Server verwenden. Aber an sich ist die Wahl des Transaction-Managers sowieso etwas, was man auch erst beim Deployment entschieden wird - und dabei kann das Monitoring der JTA-Transaktionen in einem Application Server ein wichtiger Punkt sein, weil dadurch der Betrieb die Anwendung besser betreuen kann. Allerdings bekommt man bei den JTA-Transaktionen keine Möglichkeit, geschachtelte Transaktionen zu unterstützen.

Bei Spring ist die Nutzung der Transaktionen transparent, d.h. man muss nichts besonderes machen, damit der Persistenz-Code an den Transaktionen teilnimmt. Dabei wird auch z.B. automatisch die richtige Hibernate-Session für die aktuelle Transaktion verwendet. Bei JMS gibt es bei Transaktionen die Möglichkeit, per XA dafür zu sorgen, dass sowohl die Verarbeitung der Nachrichten bestätigt und auch die Datenbank-Transaktionen dann abgeschlossen ist. Wenn man kein XA verwendet, bekommt man die Nachricht eventuell ein zweites Mal, was nicht sehr schlimm ist in den meisten Szenarien, aber deutlich schneller ist.

Fazit: Viele Anwendungen könnten mit nativen Transaktionen funktionieren - und zwar wesentlich effektiver.

Labels: Jürgen Höller, Spring, WJAX

  ¶ 18:35