Transaktionsmonitore - Grundlagen

Friedrich-Schiller-Universität Jena
Fakultät für Mathematik und Informatik
Institut für Informatik
Lehrstuhl für Datenbanken und Informationssysteme
Transaktionsmonitore
–Grundlagen–
Ausarbeitung zum Seminar:
„Großrechneraspekte (Mainframe): Von Betriebssystemen bis zur Datenbank und
darüber hinaus“
Sommersemester 2003
Leitung: Knut Stolze
vorgelegt von:
Andreas Hähnel
6. Fachsemester Informatik Diplom
Schlegelstr. 8/507
07747 Jena
Jena, den 16. Juni 2003
Inhaltsverzeichnis
.
.
.
.
.
1
1
1
2
2
3
2
Stored Procedures
2.1 Arbeitsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
6
3
Transaktionsmonitore
3.1 Aufbau . . . . . . . . . . . . .
3.2 Sicherstellung der Atomarität
3.3 Flat Transaction . . . . . . . .
3.4 LUW – Logical Unit of Work .
3.5 Two-Phase Commit-Protokoll
1
4
Einführung
1.1 Transaktionen . . . . . . . . . . . . .
1.2 ACID-Eigenschaften . . . . . . . . .
1.3 Zwei-Tier-/Drei-Tier-Konfiguration
1.3.1 Zwei-Tier . . . . . . . . . . .
1.3.2 Drei-Tier . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Transaktionsmonitore vs. Stored Procedures
Literaturverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
10
10
10
12
14
15
1
1.1
Einführung
Transaktionen
„Transaktionen sind Client/Server-Anwendungen, welche die auf einem Server gespeicherten Daten von einem definierten Zustand in einen anderen überführen. Eine
Transaktion ist eine atomare Operation: Die Transaktion wird entweder ganz oder
gar nicht durchgeführt.“[HKS03] Nach diesem Zitat sollen die in dieser Ausarbeitung behandelten Transaktionen definiert sein, wobei zu beachten ist, Transaktionen nicht nur im ‚engen‘ Sinn von Datenbanktransaktionen zu betrachten. Vielmehr geht es um die sogenannten Business Transaktionen, zum Beispiel die monatliche Zinsabrechnung von Darlehenskonten bei einer Bank[HKS03]. Diese setzen sich
aus mehreren Schritten zusammen, die unter anderem Datenbanktransaktionen sein
können: Darlehenkonto abrechnen, Tilgung und Zinsen auf Sollseite buchen, globales Limit überprüfen, ...
Ein weiterer Ansatz sind die E-Business B2B (Business-to-Business)-Komponenten,
bei denen Aktionen zwischen verschiedenen Unternehmen vollautomatisch über
das Internet abgewickelt werden. Transaktionen, die von einem menschliches Sachbearbeiter ausgelöst wurden können viele Folgetransaktionen nach sich ziehen, die
von Computer zu Computer generiert werden, zum Beispiel[GR99a]: Die Buchung
einer Reise benötigt Flugreservierungen, Buchungen für die gewünschten Hotels,
eine Transaktion zum Erstellen des Tickets, eine zum Ausdrucken der Rechnung
und so weiter.
1.2
ACID-Eigenschaften
Ein Nutzer, der eine Transaktion veranlaßt, möchte sichergehen, daß diese im Ganzen erfolgreich ausgeführt wird. Außerdem vertraut er darauf, daß kein anderer
Nutzer für ihn relevante Daten während seiner Transaktionsverarbeitung verändert.
Nach dem bestätigten Transaktionsende müssen die Datenänderungen zumindest
so gespeichert sein, daß diese nach einem Crash wiederhergestellt werden können.
Diese und andere Forderungen werden an transaktionsverarbeitende Systeme gestellt und sind in den sogenannten ACID-Eigenschaften zusammengefaßt:
Atomicity: Eine Transaktion wird entweder ganz oder gar nicht ausgeführt, d.h.
wenn eine Transaktion aus welchem Grund auch immer (z.B. Fehler in der
1
Kommunikation zwischen Klient und Server) nicht zu Ende geführt wird,
setzt das System alle Änderungen auf den Stand vor Transaktionsbeginn zurück.
Consistency: Das System soll sich vor Beginn und nach Ende der Transaktion in
einem konsistenten Zustand befinden, während einer Transaktion kann das
nicht gewährleistet werden, da so keine Änderungen möglich wären. Als Konsequenz müssen Transaktionen, die ein nicht konsistentes System hinterlassen,
sei es durch Fehler in der Verarbeitung oder durch Anweisungen, die nie in einem konsistenten System enden, zurückgesetzt werden.
Isolation: Jeder Anwender auf dem System soll sich so ‚fühlen‘, als wäre er der
alleinige Nutzer der von ihm beanspruchten Ressourcen. Diese Ziele können
durch geeignetes Sperren von Ressourcen erreicht werden. Mit Isolation soll
verhindert werden, daß andere Transaktionen Daten ändern, die zur Ausführung benötigt werden.
Durability: Nach erfolgreichem Ende einer Transaktion sollen die veränderten Daten fest gespeichert sein und dürfen durch keinen Umstand verloren gehen,
bei Systemversagen müssen die Daten z. B. durch Nachfahren der Transaktion
oder Nutzung des Backups wiederhergestellt werden.
1.3
Zwei-Tier-/Drei-Tier-Konfiguration
Diese Art der Konfiguration beschreibt Systeme bezüglich der Anzahl der Stufen
(engl. tier), in denen das System aufgebaut ist. Unterschiede treten sowohl in der
Zahl der eingesetzten Server, als auch bei der damit erzielten Performance und den
entstandenen Kosten für Anschaffung und Wartung auf.
1.3.1
Zwei-Tier
In Abbildung 1 ist die schematische Darstellung der Zwei-Tier-Konfiguration zu sehen. Diese Zwei-Stufen-Architektur ist durch einen Klient-PC, an dem der Anwender arbeitet, und einen Server zur Datenhaltung charakterisiert. Zur Kommunikation zwischen Klient und Server kommt ein geeignetes Netzwerk zum Einsatz, falls
beides getrennte Rechner sind, ansonsten übernimmt der Betriebssystemkernel diese Aufgabe. Der vom Klient bereitgestellte SQL-Client (falls serverseitig ein relatio-
2
nales Datenbanksystem wie z. B. DB2 verwendet wird) nimmt SQL-Anweisungen
entgegen und setzt diese in für den Server verständliche Datenbankaufrufe um. Anwendungen für diese Form der Konfiguration werden häufig in Visual Basic, Java
oder C/C++ entwickelt.
Abbildung 1: Schema 2-Tier-Konfiguration
Der Zwei-Tier-Konfiguration sind jedoch Grenzen bezüglich Anzahl der Benutzer
und Komplexität der Anwendungen gesetzt. Sie ist geeignet zum Einsatz in LANUmgebungen bei wenigen Servern und mäßigen Sicherheitsanforderungen. Desweiteren sollten zumeist einfache Transaktionen bei wenigen Klienten und einer
relativ geringen Anzahl von Transaktionen pro Zeiteinheit benutzt werden. Gründe
für die schlechte Skalierbarkeit sind das erzeugte Datenvolumen auf dem Netzwerk,
die Verteilung der Klient-Software, welche auf jedem der Klienten separat installiert
und gewartet werden muß sowie die durch Access Control Lists (ACL) gegebene Sicherheit. Der Nachteil von ACL ist, daß Rechte zum Zugriff auf Daten, aber nicht auf
Servicebasis gegeben werden können. Das Granulat der Rechtevergabe ist zu grob.
In Abbildung 3 auf ist die Kostenkurve im Vergleich zur Drei-Tier-Konfiguration zu
sehen, an der deutlich wird, daß sich die zwei-stufige Architektur nur in kleinen,
überschaubaren Systemen bewähren kann.
1.3.2
Drei-Tier
Die in Abbildung 2 gezeigte Drei-Tier-Konfiguration ist in der Lage, die im vorangegangegen Abschnitt aufgetauchten Probleme zu lösen. Das Hauptmerkmal und
damit der Hauptunterschied zur Zwei-Tier-Konfiguration ist die eingeführte Zwischenstufe der Anwendungsserver. Dem Klient obliegt nur noch die Präsentation
3
der ihm übergebenen Daten und der Aufruf von Services. Durch den Anwendungs-
Abbildung 2: Schema 3-Tier-Konfiguration
server können die Applikationen zentral installiert und gewartet werden, es ist zudem möglich, mehrere dieser Server einzusetzen. Außerdem generieren die Service-Anforderungen weniger Datenvolumen und die Zugriffskontrolle erfolgt auf
Service-Basis, das heißt, der Anwender hat keinen direkten Zugriff auf die Daten.
Dazu lassen sich die Zugriffsrechte viel feiner verteilen als das bei der zweistufigen
Architektur möglich ist.
Durch die Unterschiede zur Zwei-Tier-Konfiguration sklaliert diese Architektur bei
komplexeren und größeren Umgebungen wesentlich besser.
2
2.1
Stored Procedures
Arbeitsweise
Ein Anwendungsprogramm verwendet zum Zugriff auf Daten in relationalen Datenbanken embedded SQL-Anweisungen. Die Einleitung einer solchen Anweisung
erfolgt über exec sql, womit der Precompiler diese von anderen Programmzeilen
unterscheiden kann. SQL-Transaktionen besitzen ACID-Eigenschaften (bei Verwendung von Datenbanksystemen wie DB2 oder Oracle) ebenso wie Gruppen von SQLAufrufen, die zwischen den (u. U. impliziten) Anweisungen begin_transaction
und commit bzw. rollback stehen und entweder ganz oder gar nicht ausgeführt
werden sollen. Ein Programmfragment kann in C zum Beispiel so aussehen:
4
Abbildung 3: Kostenvergleich beider Konfigurationen[HKS03]
void function_1() {
.........
.........
exec sql select * from Tabelle1 where a=b order by a;
.........
.........
}
Das Datenbank-Management-System (DBMS) wird normalerweise als ein eigener
Prozeß mit einem eigenen virtuellen Adreßraum ausgeführt, so daß es gleich ist, ob
die Datenbank auf dem gleichem Rechner oder entfernt arbeitet.
Mit einer Stored Procedure können mehrere Datenbankanweisungen gebündelt werden. In der Anwendung werden diese Anweisungen durch einen Aufruf der Stored
Procedure mit eventuell vorhandenen Parametern ersetzt. Die Gruppe von Anweisungen werden im Programm implementiert, vorkompiliert und liegen im Datenbankprozeß zum Aufruf bereit. Vorteile durch die Nutzung von Stored Procedures
liegen vor allem im besseren Leistungsverhalten gegenüber einzelnen Aufrufen im
Programm, da die Anweisungen vorkompiliert bereitliegen und geringere Netzlast
verursachen als statische SQL-Anweisungen. Der Performancegewinn schlägt sich
umso mehr nieder, wenn die Transaktionen mehrmals während der Laufzeit aufgerufen werden. Abbildung 4 zeigt die Nutzung von Stored Procedures. In diesem
5
Beispiel befinden sich Anwendung und Datenbank auf dem gleichen Rechner und
tauschen sich über den Betriebssystemkernel aus.
Abbildung 4: Funktionsweise von Stored Procedures
2.2
Implementierung
Zur Implementierung von DBMS und im speziellen auch Stored Procedures unter Berücksichtigung der ACID-Eigenschaften existieren zwei unterschiedliche Ansätze[HKS03].
Der optimistische Ansatz baut darauf, daß während der Ausführung kein anderer
Prozeß auf die Daten zugreift, ansonsten erfolgt ein rollback:
• Daten mit Zeitstempel (oder Versions-Nr.) versehen, z.B. zusätzliches Feld in
SQL-Tabelle,
• Daten verarbeiten,
• if Zeitstempel unchanged then commit else rollback.
Falls sich die rollbacks häufen, wirkt sich das negativ auf die Leistungsfähigkeit des
Systems aus und man greift zum pessimistischen Ansatz:
• Daten mit Lock versehen,
• Daten verarbeiten,
6
• Ergebnis speichern,
• Reset Lock.
3
Transaktionsmonitore
Transaktionsmonitore sind eine Implementation der Drei-Tier-Konfiguration (siehe
Abschnitt 1.3.2) und Bestandteil eines Transaktionsverarbeitungssystems, welches
außerdem Anwendungen, Datenbanken, Netzwerksteuerung und Entwicklungswerkzeuge umfaßt. Ein Transaktionsmonitor ist eine „Software used to create, execute and manage transaction processing applications“[Sch03]. Damit ist eine Umgebung definiert, die Anwendungen mit Anfragen auf großen, zum Teil verteilten
Systemen verwaltet und effizient laufen läßt, die es vielen Anwendern erlaubt, diese Anfragen zu stellen und die in der Lage ist, mehrere Server zur Bearbeitung der
Anfragen einzubinden. Folgende Kernfunktionen stellen Transaktionsmonitore für
ein Transaktionsverarbeitungs-System bereit[HKS03]:
• Message Queuing
• Lock-Verwaltung
• Log-Verwaltung
• Two-Phase Commit-Synchronisation
• Rollback-Funktion
• Laststeuerung (Load Balancing)
Produktbeispiele für Transaktionsmonitore sind das Customer Information Control System (CICS) von IBM, Tuxedo von BEA, Microsoft Transaction Server (MTS) und
viele mehr.
Im nächsten Abschnitt sollen allgemein der Aufbau und die Komponenten eines
Transaktionsmonitors erläutert werden, die darauf folgenden Abschnitte stellen kurz
spezielle Funktionen der Transaktionsmonitore vor.
7
Abbildung 5: Komponenten eines Transaktionsmonitors
3.1
Aufbau
In die Betriebssysteme Guardian von Compaq/Tandem und Transaction Processing
Facilities (TFP) von IBM sind Transaktionsmonitorfunktionen integriert, normale Betriebssysteme sind jedoch vor allem für Stapelverarbeitung und nicht für die gleichzeitige Verarbeitung vieler Anfragen ausgelegt. Aus diesem Grund läuft der Transaktionsmonitor in der Regel als ein Anwendungsprozeß auf dem Betriebssystem.
Die Nutzung von Funktionen des Betriebssystems wird vom Transaktionsmonitor
möglichst vermieden, viele Produkte bieten für höhere Leistung und Durchsatz eigene Message- und Queuing-Systeme und manchmal sogar eigene Dateisysteme (z.
B. bei CICS).
In Abbildung 5 sind die Komponenten eines Transaktionsmonitors schematisch dargestellt. Die Kommunikation zwischen Anwender und Transaktionsmonitor erfolgt
über Nachrichten (Messages), dazu läuft auf dem PC oder Terminal ein User-InterfaceProzeß, der eingegebene Daten in Nachrichten umwandelt, die der Transaktionsmonitor versteht und diese versendet. In entgegengesetzter Richtung kann der Prozeß
Nachichten empfangen und sie in geeigneter Form auf dem Bildschirm darstellen.
8
Die Wiedergabe erfolgt entweder in Textform, man spricht von einem Character User
Interface (CUI) oder (in heutiger Zeit wahrscheinlicher) über eine graphische Oberfläche, Graphical User Unterface (GUI) genannt.
Das zentrale Element des Transaktionsmonitors ist der Ressourcemanager, der für
jede Anwendung im System existiert. Bei geeigneter Konfiguration kann ein Ressourcemanager mehrere Transaktionen gleichzeitig bearbeiten, da er multithreaded
arbeitet. Hier wird auch überwacht, daß nur berechtigte Anwender diese Services
nutzen können[GR99b].
Eine Transaktion wird in drei Subtransaktionen aufgeteilt, im ersten Schritt wird sie
mit einer Transaktionidentifikationsnummer (TRID) versehen und nach erfolgreicher Autorisation in die Eingabe-Queue eingestellt. Dieser Vorgang besitzt ACIDEigenschaften und aus diesem Grund werden die Ein- und Ausgabe-Queue persistent gespeichert, um beide nach einem Crash wiederherstellen zu können. Im zweiten Schritt wird, gesteuert durch den Scheduler, die Transaktion aus der EingabeQueue entnommen, durch den Ressourcemanager verarbeitet und das Ergebnis in
die Ausgabe-Queue eingestellt, der Eintrag in der Eingabe-Queue wird entfernt. Die
letzte Subtransaktion gibt den Eintrag aus der Ausgabe-Queue an den Klienten und
entfernt ihn aus der Queue. Alle drei Subtransaktionen schließen jeweils mit einem
commit ab.
Die Isolation der ACID-Eigenschaften wird durch den Lock-Manager sichergestellt,
welcher bestimmte Datenteile blockiert und diese in einer eigenen Datenbank festhält. Der Lock-Manager ist nicht mit dem Lock-Manager eines Datenbanksystems
zu verwecheln.
Symbolhaft ist in Abbildung 5 die SQL-Datenbank als Datenhaltungssystem dargestellt, das per SQL mit dem Ressourcemanager und mit dem Lock-Manager kommuniziert. Natürlich kann ebenfalls mit einem anderen System, z.B. einem einfachen Dateisystem gearbeitet werden.
Log-Manager und Recovery-Manager sichern gemeinsam die Atomarität der Transaktionen. Beide sind Teil des Transaktionmonitors und nicht der Datenbank. Durch
den Log-Manager werden alle Änderungen festgehalten und in der Log-Datenbank
gespeichert, im Fehlerfall greift der Recovery-Manager darauf zu.
Im Repository werden Benutzerdaten und -rechte, Anwendungen und deren vorhergehende Versionen sowie Prozeduren und Bildschirminhalte des Transaktionsmonitors festgehalten.
9
3.2
Sicherstellung der Atomarität
Die wichtige Funktion zur Sicherstellung der Atomizität von Transaktionen ist das Backward Recovery, in anderen Systemen auch als
Rollback oder Abort bekannt, teilweise ausgeführte Transaktionen
werden im Fehlerfall zurückgesetzt werden. Transaktionsmonitore arbeiten mit einem Zwischenpuffer (siehe Abbildung 6), in welAbbildung 6: Backward Recovery bei TM
chem zu ändernde Datensätze vor
der Veränderung im Puffer auf Plat-
te gesichert werden (1). Im nächsten Schritt werden die Daten geändert (2), auch das
Commit-Signal wird persisten auf den Plattenspeicher gesichert (3). Der Abschluß
der Transaktion wird mit einem acknowledgement-Signal gesichert (4), erst danach
kann der Zwischenpuffer wieder zurückgesetzt werden (5)[HKS03].
Falls ein Rollback, sei es ein Fehlerfall oder ein vom Benutzer veranlaßter Abbruch,
ausgelöst wird, sind alle Daten noch im Zwischenpuffer zur Verfügung und werden
vom Backward-Recovery-Prozeß benutzt, um die Daten wiederherzustellen.
3.3
Flat Transaction
Die einfachste Art der Transaktionen stellen die Flat Transactions dar, die eine Basis
zur Organisation atomarer Aktionen aus Anwendungsebene sind. Eine Flat Transaction darf aus beliebig vielen einzelnen Aktionen bestehen. Sie wird ‚flach‘genannt,
da alle Aktionen zwischen begin und commit auf einer Ebene stehen, d.h. Transaktionen in der Transaktion (nested transactions) sind verboten. Der größte Nachteil
ist die fehlende Möglichkeit, Teile der Transaktion zurückzusetzen oder vorzeitig
mit einem commit abzuschließen.
3.4
LUW – Logical Unit of Work
Ein Ressourcemanager führt während seiner Arbeit Aktionen aus, wobei zwischen
geschützten und nicht geschützten Aktionen unterschieden wird. Für ungeschützte
Aktionen können keine ACID-Eigenschaften garantiert werden, dagegen haben ge-
10
schützte Aktionen diese Eigenschaften und werden als Logical Unit of Work (LUW)
bezeichnet.
Als nicht geschützt werden physikalisch die Umwelt beeinflussende Aktionen (auch
reale Aktionen genannt) gesehen, die nur schwer oder gar nicht rückgängig gemacht werden können. Beispiele hierfür sind:
• Abschuß einer Rakete
• Bohren eines Loches
• Magnet in der Nähe einer Diskette
Abbildung 7: Crash bei Logic Unit of Work (LUW)
Synchronisationspunkte werden dazu genutzt, zeitintensive Transaktionen in mehrere LUWs aufzuteilen, um im Fehlerfall die Transaktion nur bis zum letzten Synchronisationspunkt zurücksetzen und nicht die gesamte Transaktion wiederholen
zu müssen. In Abbildung 7 ist diese Situation anschaulich dargestellt: Bei Ausführung der Transaktion ohne Synchronisationspunkte müßte diese bis zum Begin Of
Transaction (BOT) zurückgesetzt werden. Für viele der Transaktionen wäre das vertretbar, da ihr Lauf nur wenig Zeit beansprucht, aber es gibt auch zeitintensive Anwendungen wie zum Beispiel die monatliche Zinsabrechnung von Darlehenskonten
bei einer Bank. Diese besteht aus folgenden Schritten[HKS03]:
1. Darlehenskonto abrechnen, Saldo um Tilgungsrate verändern,
2. Tilgung und Zinsen im laufenden Konto (Kontokorrent) auf der Sollseite buchen,
3. globales Limit überprüfen,
11
4. Bilanzpositionen (Konten),
5. G+V-Positionen (Gewinn- und Verlustkonten),
6. Zinsabgrenzung monatlich für jährliche Zinszahlung,
7. Bankmeldewesen (ein Kunde nimmt je 90000,- Euro bei 10 Banken auf, läuft
am Stichtag).
Eine solche Transaktion wird wahrscheinlich nicht nach wenigen Sekunden fertig
sein, sondern kann im Falle einer großen Bank mehrere Stunden dauern. Tritt ein
Fehler am Ende der Verarbeitung der sechsten Aktion auf, so muß ohne Unterteilung in LUWs die gesamte Transaktion wiederholt werden, obwohl die vorhergehenden Aktionen fehlerfrei terminierten.
3.5
Two-Phase Commit-Protokoll
Im Modell der flachen Transaktionen werden Transaktionen auf genau einem Rechner mit einem Transaktionmonitor und einem Datenbanksystem verarbeitet. Die
Praxis verlangt aber häufig die Interaktion verschiedener Systeme bei der Verarbeitung einer Transaktion, zum Beispiel beim Kauf eines Artikels mit Kartenzahlung.
Das Problem wird gelöst, indem eine Haupttransaktion (Main Transaction) Subtrans-
Abbildung 8: Two-Phase Commit-Protokoll
aktionen auf verschiedenen Systemen startet und überwacht (siehe Abbildung 8).
12
Mit dem Two-Phase Commit-Protokoll werden die ACID-Eigenschaften der Haupttransaktion sichergestellt, der Commit Coordinator (Master) überwacht die Arbeit der
Slaves. Zum Verarbeiten der Transaktionen werden folgende Schritte getätigt:
1. Master vergibt Aufgaben an Slaves
2. Slaves arbeiten
3. Master fragt nach Commit der Slaves, wartet auf diese
4. Falls alle Slaves Commit gegeben haben, gibt Master Commit, sonst Rollback
(alle Subtransaktionen müssen zurückgesetzt werden)
5. Slaves geben Daten und Locks frei und senden Acknowledgement
Am Beispiel des Kaufs eines Artikels und dessen Bezahlung mit Karte bedeutet das
folgende Aktionen:
1. Anweisung der Lastschrift (in der Regel über Inkassounternehmen) an das
Konto des Kunden
2. Abbuchen des geforderten Betrags
3. Gutschrift des Betrags auf das Konto des Geschäfts
Das Two-Phase Commit-Protokoll sichert zum Beispiel, falls die Abbuchung wegen
Kontoüberziehung nicht klappt, auch keine Gutschrift erfolgt. Abbildung 9 zeigt
den Zusammenhang zwischen Slaves und Commit Coordinator.
Abbildung 9: Beispiel Two-Phase Commit
13
Abbildung 10: Vergleich von Stored Prcedures (links) und Transaktionsmonitoren
4
Transaktionsmonitore vs. Stored Procedures
Schon durch die Architektur (Zwei-/Drei-Tier-Konfiguration) treten Performanceunterschiede beider Produkte zu Tage. Ein großer Nachteil der Stored Procedures im
Gegensatz zu Transaktionemonitoren ist, wie in Abbildung 10 dargestellt, daß für
jeden Klienten ein eigener Serverprozeß benötigt wird. Das bedeutet bei 10 offenen
Dateien pro Prozeß und 1000 Verbindungen 10000 geöffnete Dateien. Ein Transaktionsmonitor arbeitet mit wenigen Verbindungen zum Server und reduziert so die
Anzahl der offenen Dateien. Die Klienten verbinden sich mit diesem Transaktionsmonitor, welcher die Kommunikation mit dem Server erledigt. In neueren Produkten arbeiten Stored Procedures multithreaded und benötigen deshalb weniger Verbindungen zum Server, kommen aber trotzdem nicht an die Leistungsfähigkeit von
Transaktionsmonitoren heran. Desweiteren bewältigen Transaktionsmonitore hohes
Verkehrsaufkommen im Netzwerk, haben kurze Antwortzeiten und hohe Verfügbarkeit.
Durch das Two-Phase Commit-Protokoll wird die Zusammenarbeit mehrerer Transaktionsmonitore sowie der Einsatz in heterogenen Datenbanksystemen ermöglicht.
Außerdem spricht die Leistungsfähigkeit für Transaktionsmonitore, denn nahezu
alle TP-Benchmarks werden mit Transaktionsmonitoren durchgeführt[TPC03].
Einziger Nachteil der Transaktionsmonitore sind die hohen Anschaffungskosten.
14
Literatur
GR99a G RAY, Jim ; R EUTER, Andreas. The Whirlwind Tour in: Transaction Processing
- Concepts and Techniques. http://research.microsoft.com/~gray/
WICS_99_TP/01_WhirlwindTour.ppt. August 1999
GR99b G RAY, Jim ; R EUTER, Andreas. TP Monitors And ORBs in: Transaction Processing - Concepts and Techniques. http://research.microsoft.com/
~gray/WICS_99_TP/05_TPMonORBs.ppt. August 1999
HKS03 H ERRMANN, Paul ; K EBSCHULL, Udo ; S PRUTH, Wilhelm G.: Einführung
in z/OS und OS/390: Web-Services und Internet-Anwendungen für Mainframes.
München; Wien; Oldenbourg : Oldenbourg Wissenschaftsverlag, 2003
Sch03 S CHWARZ, Holger:
Transaction Monitors.
http://www.informatik.
uni-stuttgart.de/ipvr/as/lehre/skripte/TRSWS0203/
Kapitel2_Teil1.pdf. Wintersemester 2002/2003. – Skript zur Vorlesung
‚Transaktionssysteme, Parallele und verteilte Datenbanksysteme‘
TPC03 TPC. ORG. Transaction Processing Performance Council. http://www.tpc.
org. Juni 2003
15