| |
18
Neue Konzepte für das Management verteilter Systeme, Hauptseminar, LMU München WS 00/01
Dieser Vorgang bedarf einer Transaktion: Die Datenbank-Operationen müssen
entweder beide gelingen oder beide scheitern, sonst entsteht eine Inkonsistenz zwi-
schen beiden Datenbanken.
Abbildung 11: Beispiel-Szenario zu verteilten Transaktionen
Ein verteilter Transaktionsdienst, der vom Container gesteuert wird, übernimmt
diese Aufgabe. Um dies zu bewirken, muss der Application Assembler lediglich das
Transaktionsattribut für die Methode Einkaufswagen.wähleArtikel() auf
TX_REQUIRED_NEW setzen. Die Transaktion läuft bis zum nächsten Aufruf der Me-
thode. Dann wird die Transaktion abgeschlossen, um durch eine neue (NEW) ersetzt
zu werden.
Die Aufrufe von Lagerartikel.bucheAb() und Bestellung.fügeHinzu()
sind in die Transaktion mit einbezogen (da sie innerhalb von Einkaufswa-
gen.wähleArtikel() erfolgen). Um die Integrität der Anwendung sicherzustel-
len, kann der Assembler für bucheAb() und fügeHinzu() das Attribut
TX_MANDATORY setzen, das einen Fehler erzeugt, falls beim Aufruf keine Transakti-
on läuft.
Der Deployment-Deskriptor enthielte dann folgende Einträge:
Einkaufswagen.wähleArtikel()
TX_REQUIRED
Lagerartikel.bucheAb()
TX_MANDATORY
Bestellung.fügeHinzu()
TX_MANDATORY
Tritt irgendwo im System, z.B. im Netzwerk, während einer Transaktion ein Feh-
ler auf (eine Exception wird geworfen) , so wird die Transaktion automatisch ab-
gebrochen (gilt für System-Exceptions).
Alternativ können die Transaktionsgrenzen (transaction demarcation) auch vom
Programmtext der Bean selbst gesteuert werden. Für eine solche Bean muss der Bean
Provider im Deployment-Deskriptor „bean-managed transaction demarcation“ ein-
stellen (im Gegensatz zu „container-managed transaction demarcation“).
|  |
|
| |
|
|
