Behandlung von Transaktionen
Eine ähnliche Situation liegt bei der Transaktionsunterstützung vor. Auch hier sind im EJB-Standard zwei Varianten vorgesehen: Container Managed Transactions (CMT) und Beans Managed Transactions (BMT). Ähnlich wie bei den Datenbankzugriffen übernimmt bei CMT der EJB-Container die Transaktionssteuerung und bei BMT der Bean-Entwickler.
Bei CMT wird jede Methode mit einem Transaktionsattribut (in EJB 3.0 über Annotationen) beschrieben. Der Parameter gibt an, wie die Java-Methode in eine Transaktion einzubinden ist. Anwender sollten die Attributvergabe einheitlich gestalten, indem sie das Attribut "Required" in allen Methoden setzen. Bei dieser Variante wird jeder Methodenaufruf innerhalb einer Transaktion ausgeführt. Dies mag zwar etwas auf die Leistung drücken, ist aber leichter nachzuvollziehen als eine Mischung verschiedener Transaktionsattribute in einer Anwendung.
Was Sie beachten sollten
-
Nutzung von robusten, optimierbaren Datenbankzugriffs-Schnittstellen;
-
wenn möglich auf verteilte Transaktionen verzichten;
-
die Transaktionsverarbeitung sollte einfach programmiert sein (eine Transaktion je Client-Request);
-
zustandslose Komponenten verwenden, die sich einfach auf Cluster verteilen lassen;
-
Verteilung von Enterprise Javabeans einer Anwendung auf heterogene EJB-Container vermeiden;
-
vor allem bei großen Anwendungen sollte man nicht auf Container-Managed Persistence zurückgreifen;
-
keine Veränderung der EAR-Dateien bei der Inbetriebnahme (besser ist hier die Konfiguration über eine Datenbank);
-
mandantenspezifische Beans in eigenen EJB-Containern ablaufen lassen.
Container-managed Transaktionen sind jedoch mit Vorsicht zu genießen. Robuster ist die BMT-Variante. Bei nur einer Datenbank ist BMT sinnvoller.
Implementierungsfragen
Für BMT gibt es zwei Realisierungsvarianten. Entweder programmiert der Softwareexperte eine direkte Transaktionskontrolle über die Datenbankmechanismen oder er nutzt das für die Transaktionssteuerung vorgesehene Java Transaction API (JTA) zur Angabe der Transaktionsgrenzen. JTA ist notwendig, wenn man mehrere Datenbanken innerhalb einer Transaktion bedienen muss.
Zwar könnte auch ein EJB-Client die Transaktionsgrenzen setzen. Dies sollte aber vermieden werden. Der Grund: Stürzt der Client während der Transaktionsverarbeitung ab, hat der Server Probleme, den Vorgang zurückzusetzen. Eine Transaktion sollte daher immer im Server beginnen und enden. Nicht empfehlenswert sind Transaktionen, die mehr als eine entfernte Methode aufrufen. Der Rat lautet hier, eine abgeschlossene Transaktion pro Client-Request (entfernter Methodenaufruf). Dies mag kein perfekter Ansatz sein, vermeidet aber einige Schwierigkeiten beim Wideranlauf nach Fehlersituationen. Werden Daten über mehrere Client-Requests bearbeitet, sollte in der Anwendung ein optimistisches Sperren über Datenbanktransaktionen hinweg realisiert werden. Vor jeder Änderung eines Datenbankobjekts muss im Server abgefragt werden, ob es sich seit dem letzten Lesezugriff verändert hat.