Jakarta Transactions API

Software
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 14. Oktober 2009 um 19:47 Uhr durch Sebastian.Dietrich (Diskussion | Beiträge) (Einführung von Subkategorien unter [:Kategorie:Programmiersprache Java]). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Die Java Transaction API (JTA) ist eine von Sun und dem Java Community Process spezifizierte Programmierschnittstelle (API) zur Kontrolle von Datenmanipulationen in einer Datenbank. JTA selbst kann keine Transaktionen vornehmen, sondern bietet lediglich standardisierte Methoden zur Kontrolle von Transaktionen.

Java Transaction API
Basisdaten

Hauptentwickler Java Community Process
Entwickler Sun Microsystems
Aktuelle Version 1.1.
(1. November 2002)
Betriebssystem plattformunabhängig
Programmier­sprache Java (Programmiersprache)
Lizenz Eclipse Public License 2.0, GPL linking exception
java.sun.com/javaee/technologies/jta

Die JTA-Bibliothek ist in so gut wie allen J2EE-Containern integriert. Da JTA lediglich aus Interfaces besteht, wird der Java-Entwickler meist mit JTA über Frameworks wie Hibernate, Spring, Glassfish oder TopLink in Berührung kommen. Diese Frameworks implementieren (bzw. benötigen) die JTA-Interfaces, sodass sie ein kontrolliertes Transaktions-Management gewährleisten können.

Transaktions-Management ist ein wichtiger Bestandteil geschäftskritischer DV-Anwendungen. Es zeichnet u.a. dafür verantwortlich, dass Transaktionen nur dann die Persistenz-Schicht(Datenbank) einer Anwendung dauerhaft manipulieren, wenn sie vollkommen fehlerfrei abgeschlossen werden können. Exakt dies leistet die Implementierung von JTA. Andere Kriterien wie Threadsicherheit (Nebenläufigkeit), also beispielsweise die Vermeidung von Race-Hazards, fallen nicht in den Zuständigkeitsbereich von JTA.

Da sich eine Transaktion aus verschiedenen Aktionen/Abfragen (abhängig von wiederum verschiedenen Bedingungen) zusammensetzt, kann sich ein Fehler oder eine Unzulänglichkeit inmitten des Ablaufes der Transaktion ereignen, das heißt auch dann, wenn bereits Manipulationen an der Persistenzschicht vorgenommen wurden (beispielsweise könnte ein Käufer sich ganz am Ende als zahlungsunfähig erweisen, die Transaktion kann daher nicht erfolgreich abgeschlossen werden; die Ware musste aber schon als gekauft markiert werden, um anderen Käufern denselben Artikel nicht noch einmal anzubieten). In einem solchen Fehlerfalle ist es notwendig, ein Rollback auszuführen, um die Daten der Anwendung konsistent zu halten. Der Transaktions-Manager führt also erst dann das Commit an der Datenbank durch, wenn die Transaktion vollständig und einwandfrei ausgeführt werden konnte.