J and I and Me
2007-11-06
  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: , ,

  18:35
Bookmark and Share
Comments:
Also check out the video of Juergen's talk Transaction Management Strategies in Mission Critical Applications, recorded at the Spring Experience.
 
Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff