DB2 Universal Database - Systemverwaltung


X/Open-Modell für die verteilte Transaktionsverarbeitung

Das X/Open-Modell für die verteilte Transaktionsverarbeitung (DTP - Distributed Transaction Processing) umfaßt drei in Wechselbeziehung zueinander stehende Komponenten:

Abbildung 43 veranschaulicht dieses Modell und zeigt die Beziehungen dieser Komponenten untereinander.

Abbildung 43. X/Open-Modell für die verteilte Transaktionsverarbeitung (DTP)

X/Open-Modell für die verteilte Transaktionsverarbeitung (DTP)

Anwendungsprogramm (AP)

Das Anwendungsprogramm (AP) definiert die Transaktionsgrenzen und gibt die anwendungsspezifischen Aktionen an, aus denen die Transaktion besteht.

Ein CICS*-Anwendungsprogramm möchte zum Beispiel auf Ressourcenmanager (RMs) wie eine Datenbank und eine CICS-Warteschlange mit Übergangsdaten (CICS Transient Data Queue) zugreifen und eine Programmlogik verwenden, um die Daten zu ändern. Jede Zugriffsanforderung wird an die entsprechenden Ressourcenmanager über für diesen Ressourcenmanager spezifische Funktionsaufrufe übergeben. Im Fall von DB2 können diese Funktionsaufrufe vom DB2-Precompiler für jede SQL-Anweisung generiert worden sein, oder es kann sich um Datenbankaufrufe handeln, die direkt vom Programmierer mit Hilfe der APIs codiert wurden.

Zum Transaktionsmanagerprodukt (TM-Produkt) gehört in der Regel ein Transaktionsverarbeitungsmonitor (TP-Monitor) zur Ausführung der Benutzeranwendung. Der TP-Monitor stellt APIs bereit, die einer Anwendung die Möglichkeit geben, eine Transaktion zu starten und zu beenden, und die Funktionen zur Terminierung der zeitlichen Abläufe von Anwendungen sowie zum Lastausgleich unter den vielen Benutzern, die die Anwendung ausführen möchten, zur Verfügung stellen. Das Anwendungsprogramm (AP) in einer DTP-Umgebung ist im Grunde eine Kombination aus der Benutzeranwendung und dem TP-Monitor.

Um eine effiziente Online-Transaktionsverarbeitung (OLTP, Online Transaction Processing) zu ermöglichen, ordnet der TP-Monitor eine Reihe von Server-Prozessen beim Start im voraus zu und verwaltet und verwendet diese anschließend für die zahlreichen Benutzertransaktionen. Auf diese Weise werden Systemressourcen eingespart, da mehr Benutzer mit Hilfe einer geringeren Anzahl von Server-Prozessen und ihrer zugehörigen RM-Prozesse unterstützt werden. Durch die mehrfache Verwendung dieser Prozesse wird auch der Systemaufwand vermieden, der mit dem Starten eines Prozesses im Transaktionsmanager oder den Ressourcenmanagern (RM) für jede Benutzertransaktion bzw. jedes Benutzerprogramm verbunden ist. (Ein Programm ruft ein oder mehrere Transaktionen auf.) Dies bedeutet auch, daß die Server-Prozesse gegenüber dem Transaktionsmanager und den Ressourcenmanagern als die wirklichen "Benutzerprozesse" auftreten. Hieraus ergeben sich bestimmte Konsequenzen für die Sicherheitsverwaltung und die Anwendungsprogrammierung. Nähere Informationen finden Sie in Überlegungen zur Sicherheit.

Die folgenden Arten von Transaktionen sind von einem TP-Monitor aus möglich:

Transaktionsmanager (TM)

Der Transaktionsmanager (TM) ordnet Transaktionen Kennungen zu, überwacht die Verarbeitung von Transaktionen und ist zuständig für die Beendigung bzw. für Fehler der Transaktionen. Die Kennungen für Transaktionsverzweigungen (XIDs) werden vom Transaktionsmanager zugeordnet, um die globale Transaktion und die spezielle Verzweigung innerhalb eines Ressourcenmanagers (RM) zu identifizieren. Diese Kennung ist das Korrelations-Token zwischen dem Protokoll in einem Transaktionsmanager (TM) und dem Protokoll in einem Ressourcenmanager (RM). Die XID wird für eine zweiphasige Festschreibung bzw. für eine ROLLBACK-Operation benötigt, um die Resynchronisation (abgekürzt resync) bei einem Systemstart durchzuführen oder um dem Administrator die Möglichkeit zu geben, bei Bedarf eine heuristische Operation (auch als manueller Eingriff bezeichnet) vorzunehmen.

Nach dem Start fordert ein TP-Monitor den Transaktionmanager auf, alle Ressourcenmanager (RMs) zu öffnen, die in einer Gruppe von Anwendungs-Servern definiert sind. Der Transaktionsmanager übergibt die xa_open-Aufrufe an die Ressourcenmanager, damit diese für die DTP-Verarbeitung initialisiert werden können. Im Rahmen dieser Startprozedur führt der Transaktionsmanager eine Resynchronisation (resync) durch, um alle unbestätigten Transaktionen aufzulösen. Eine unbestätigte Transaktion ist eine globale Transaktion, die nicht vollständig zu Ende geführt wurde. Dies geschieht, wenn auf den Transaktionsmanager (oder mindestens auf einen Ressourcenmanager) nach einer erfolgreich abgeschlossenen ersten Phase (Vorbereitunsphase) des Protokolls für zweiphasige Festschreibung nicht mehr zugegriffen werden kann. Der Ressourcenmanager weiß solange nicht, ob seine Verzweigung der Transaktion festzuschreiben oder rückgegängig zu machen ist, bis der Transaktionsmanager sein eigenes Protokoll mit den Protokollen der Ressourcenmanager abgleichen kann, wenn sie wieder verfügbar werden. Zur Durchführung der Resynchronisation setzt der Transaktionsmanager einen xa_recover-Aufruf an jeden Ressourcenmanager mindestens einmal ab, um alle unbestätigten Transaktionen zu identifizieren. Der Transaktionsmanager vergleicht die Antworten mit den Informationen im eigenen Protokoll, um zu bestimmen, ob die Ressourcenmanager angewiesen werden sollen, eine xa_commit-Operation oder eine xa_rollback-Operation für diese Transaktionen durchzuführen. Wenn ein Ressourcenmanager seine Verzweigung einer unbestätigten Transaktion aufgrund einer heuristischen Operation durch den Administrator bereits festgeschrieben oder rückgängig gemacht hat, setzt der Transaktionmanager einen Aufruf xa_forget an diesen Ressourcenmanager ab, um die Resynchronisation abzuschließen.

Wenn eine Benutzeranwendung eine COMMIT- oder ROLLBACK-Operation anfordert, muß sie die vom TP-Monitor oder Transaktionmanager bereitgestellte API verwenden, so daß der Transaktionmanager die COMMIT- und ROLLBACK-Operation unter allen beteiligten Ressourcenmanagern koordinieren kann. Wenn zum Beispiel eine CICS-Anwendung die CICS-Anforderung SYNCPOINT absetzt, um eine Transaktion festzuschreiben, setzt der Transaktionsmanager CICS XA TM (im Encina-Server implementiert) seinerseits die entsprechenden XA-Aufrufe wie xa_end, xa_prepare, xa_commit oder xa_rollback ab, um den Ressourcenmanager anzuweisen, die Transaktion festzuschreiben oder rückgängig zu machen. Der Transaktionsmanager kann eine einphasige Festschreibung anstelle der zweiphasigen Festschreibung durchführen, wenn nur ein Ressourcenmanager beteiligt ist oder wenn ein Ressourcenmanager antwortet, daß seine Transaktionsverzweigung im Nur-Lese-Modus arbeitet.

Ressourcenmanager (RM)

Ein Ressourcenmanager (RM) stellt den Zugriff auf gemeinsame Ressourcen wie Datenbanken zur Verfügung.

DB2 als Ressourcenmanager einer Datenbank kann an einer globalen Transaktion beteiligt sein, die von einem dem XA-Standard entsprechenden Transaktionsmanager koordiniert wird. Wie für die XA-Schnittstelle erforderlich stellt der Datenbankmanager eine externe C-Variable db2xa_switch des Typs xa_switch_t bereit, um die XA-Schalterstruktur an den Transaktionsmanager zurückzugeben. Diese Datenstruktur enthält die Adressen der verschiedenen XA-Routinen, die vom Transaktionsmanager aufzurufen sind, und die Betriebsmerkmale des Ressourcenmanagers. Weitere Informationen zu XA-Funktionen, die vom Datenbankmanager unterstützt werden, finden Sie in Unterstützte XA-Funktion.

Es gibt zwei Methoden, mit denen der Ressourcenmanager seine Teilnahme an der jeweiligen globalen Transaktion registrieren kann: statische Registrierung und dynamische Registrierung:

Eine XA-Schnittstelle stellt eine Zweiwegeübertragung zwischen einem Transaktionsmanager und einem Ressourcenmanager her. Bei der XA-Schnittstelle handelt es sich um eine Systemebenenschnittstelle zwischen den beiden DTP-Softwarekomponenten, und nicht um eine gewöhnliche Schnittstelle für Anwendungsprogramme, für die ein Entwickler Aufrufe codiert. Anwendungsentwickler sollten jedoch mit den durch DTP-Softwarekomponenten bedingten Programmiereinschränkungen vertraut sein. Informationen zu Gesichtspunkten, die bei Programmierung unter Verwendung der X/Open XA-Schnittstelle zu beachten sind, finden Sie im Handbuch Application Development Guide.

Obwohl die XA-Schnittstelle unveränderlich ist, kann jeder dem XA-Standard entsprechende Transaktionmanager einen Ressourcenmanager auf eine eigene, produktspezifische Weise integrieren. Informationen zur Integration Ihres DB2-Produkts als Ressourcenmanager mit einem bestimmten Transaktionsmanager finden Sie in der Dokumentation des entsprechenden Transaktionsmanagerprodukts. Informationen zur Integration in bezug auf die gängigsten TP-Monitore finden Sie in Konfigurieren des XA-Transaktionsmanagers zur Verwendung von DB2 UDB.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]