Kap. 2.3 Infrastruktur durch Transaction Processing Monitore ( TP-Heavy ) Workshop

Größe: px

Ab Seite anzeigen:

Download "Kap. 2.3 Infrastruktur durch Transaction Processing Monitore ( TP-Heavy ) Workshop"

Kornelius Michel
vor 8 Jahren
Abrufe

1 Kap. 2.3 Infrastruktur durch Transaction Processing Monitore ( TP-Heavy ) Workshop Vertiefung der X/Open DTP Protokolle Programmierparadigmen Verteilte Transaktionsverarbeitung (i. Vgl. zu Oracle) Optimierungen für 2PC Funktionalität und Aufbau des TP-Monitors TUXEDO Komponenten Systemarchitektur Einführung in die Übungsaufgabe Kap 2.3-1

Vertiefung der X/Open DTP Protokolle Programmierparadigmen Verteilte

2 Verteilte Transaktionsverarbeitung mit X/Open DTP Verteilte Überweisung Laufzeitumgebung des TP Monitor Client Transfer ATM TP Monitor Service Debit Credit Bern Zürich DB DB DB DB Kap 2.3-2

3 X/Open s Programmierparadigmen Service-Orientierung Bereitstellung von Funktionalität über C/COBOL-Funktionen Bekanntgabe dieser Funktionen an den TP Mon. (Advertising) sog. Request-/Response-Programmierung Konversations-Orientierung Eröffnung eines Kanals Senden von Daten und Ergebnissen über diesen Kanal Typed Buffers Strukturen zum maschinenunabh. Datenaustausch Kap 2.3-3

Request-/Response-Programmierung Konversations-Orientierung Eröffnung eines Kanals Senden von

4 Programmier-Unterstützung durch X/Open Kommunikations-Puffer tpalloc - Speicher anfordern tpfree - Speicher freigeben tprealloc -neue Speichergrösse Erstellung von Services tpservice - Template für einen Service tpreturn - Verlassen einer Service-Routine Service-Aufruf tpacall - asynchroner Aufruf tpcall - synchroner Aufruf tpcancel - Antwort verwerfen tpgetrply - Antwort zu asynchronem Aufruf holen Konversations-Routinen tpconnect - Konversation eröffnen tpdiscon - Konv. beenden tprecv - Nachricht empfangen tpsend - Nachricht senden Kap 2.3-4

tpacall - asynchroner Aufruf tpcall - synchroner Aufruf tpcancel - Antwort verwerfen tpgetrply - Antwort zu asynchronem Aufruf holen

5 Programmier- vs. Systemsicht Programmiersicht: Code, den der Applikationsentwickler schreiben muss Aufgaben: DB-Zugriff implementieren Transaktionsgrenzen setzen Aufruf anderer TP-Monitor- Services durchführen Kommunikationspufferverwaltung (!) Systemsicht: Boilerplate Code, der vom System automatisch ausgeführt wird und in TP-Monitor-Bibliotheken implementiert ist Aufgaben Verwaltung des Transaktionsbaumes gegenüber DBMSs und weiteren TP-Monitor- Instanzen Zwei-Phasen-Commit Lastbalanzierung Datenabhängiges Routing... Kap 2.3-5

Transaktionsgrenzen setzen Aufruf anderer TP-Monitor- Services durchführen Kommunikationspufferverwaltung (!

6 Programmierer-Sicht Service-Orientierung Aufrufe in den Applikationsprogrammen Client tpcall(.) tx_begin() tx_commit() Transfer ATM tpcall(char*) Debit tpreturn(.) EXEC SQL AT DB_NAME Bern DBMS tpcall(char*) Credit tpreturn(.) EXEC SQL AT DB_NAME Zürich DBMS Kap 2.3-6

) tx_begin() tx_commit() Transfer ATM tpcall(char*) Debit

7 Systemsicht: Transaktionsbaum 1 Transfer TM ax_add_branch ax_add_branch CRM tpcall ATM XID 1 XID 2 TM ax_start CRM TM ax_start CRM Debit Bern Credit Zürich DBMS DBMS Kap 2.3-7

8 Systemsicht: Transaktionsbaum 2 Transfer tx_commit xa_prepare TM xa_prepare CRM ATM xa_prepare(xid 1 ) xa_prepare(xid 2 ) TM ax_prep. CRM TM ax_prep. CRM Debit xa_prepare Bern Credit xa_prepare Zürich DBMS DBMS Kap 2.3-8

9 Systemsicht: Transaktionsbaum 3 Transfer TPEABORT XA_OK TM XA_RB CRM ATM XA_OK XA_RB TM TM_OK CRM TM TM_RB CRM Debit XA_OK Bern Credit XA_RBINTEGRITY Zürich DBMS DBMS Kap 2.3-9

10 Optimierungen im 2PC Zielsetzungen: Verminderung der Anzahl benötigter Nachrichten Verringerung der I/O auf dem Log Angewandte Techniken: presumed abort: kein Log-Eintrag - TA-Branch wurde aborted group commit: akkumuliertes Schreiben von Log-Einträgen (Log-Dämon wird alle 50msec aktiviert, TA solange verzögert) transfer-of-commit: prepare, und mit neuem TA-Branch wird dortiger TM 2PC-Koordinator lazy commit: asynch. Commit-Logging - keine Durability last-resource-manager-option: bei entarteten TA-Bäumen transfer-of-commit anwenden, so dass letzter DB als 2PC- Koordinator Kap

solange verzögert) transfer-of-commit: prepare, und mit neuem TA-Branch wird dortiger TM 2PC-Koordinator lazy commit: asynch.

11 TP Monitor TUXEDO Hersteller: Bea Systems System-Komponenten: TUXEDO System/T Administrationsschnittstelle Applikationsentwicklung Implementierung von TM, XA, XA+, XATMI TUXEDO System/D: SQL-DBMS (Resource Manager) zu System/T TUXEDO Workstation: Client-Anbindung von entfernten Rechnern TUXEDO /Q: Transaktionelle Message-Queues TUXEDO /TxRPC: Implementierung von X/Open TxRPC TUXEDO /Domain: Interoperabilität mit anderen TUXEDO Instanzen oder anderen TP Monitoren über OSI-TP Kap

XATMI TUXEDO System/D: SQL-DBMS (Resource Manager) zu System/T TUXEDO Workstation: Client-Anbindung von entfernten Rechnern

12 TUXEDO: System-Architektur TUXEDO Kernel: BBL Client call X A T M I put queue push/get CREDIT put queue push/get DEBIT Transaction Manager LOG Kap

13 TUXEDO: Mehrrechner-Architektur TUXEDO Kernel: BBL TUXEDO Kernel: BBL X A T M I queue queue CREDIT DEBIT X A T M I queue queue CREDIT DEBIT remote call stub put remote call BRIDGE Message Transmission BRIDGE Kap

X A T M I queue queue CREDIT DEBIT remote call stub

14 TUXEDO: Load-Balancing Many Services - Single Queue: sobald Service fertig, neuen Auftrag aus der Queue Many Services - Many Queues: Service- Farm ggf. auf mehreren Rechnern, Zuteilung nach Workload-Heuristik CREDIT CREDIT X A T M I CREDIT CREDIT Kap

15 Die TP-Monitor BRIDGE Herstellerspezifische Lösungen meist als eigenständiger Betriebssystem-Prozess Aufgabe an der Daten-Quelle: Entgegennahme von Aufträgen für entfernte Rechner Entgegennahme von Daten für entfernte Rechner ggf. Übersetzung der Daten in maschinenunabhängige Repräsentation (sog. Marshalling) Aufgaben Daten-Senke: gleicher Ablauf in umgekehrter Reihenfolge sowie: Positionierung des Auftrags in der richtigen Queue Ergebnisse werden auf dem gleichen Weg zurückgesandt Siehe auch Object Request Broker-Konzept im CORBA-Teil Kap

Übersetzung der Daten in maschinenunabhängige Repräsentation (sog.

16 Übungsaufgabe Zielsetzung: Programmierung einer verteilten Überweisungstransaktion mit TUXEDO Schritte: Hallo-Welt-Service mit TUXEDO Verteilte Verarbeitung einer Überweisung Sicherstellung der ACID-Eigenschaften Lerneffekte Anwendung der TX- und ATMI-Standards sowie von FML-Buffers Arbeit mit komplexem System: OS, RDBMS, TP Mon Kap

Überweisung Sicherstellung der ACID-Eigenschaften Lerneffekte Anwendung der TX- und

17 Zielsystem Client Client Transfer Transfer Deposit Withdraw Bern Deposit Withdraw Zürich STUD5 STUD2 Kap

18 TUXEDO FML-Buffers TUXEDO-spezifische Erweiterung der X/Open Typed Buffers Datenstruktur zum Austausch zwischen Rechnern tpcall(char* svc, char* idata ); Vorteil: Information durch Feldbezeichner-Wert-Paare (<fname>,<value>) z.b.: [(VORNAME, Torsten ), (NACHNAME, Grabs )] Effizienter Transfer von Puffern beliebiger Grösse Inhaltsbasiertes Routing (abhängig vom Pufferinhalt) Programmierschnittstelle: tpalloc: Anfordern dynmischen Speichers unter TP Mon.- Kontrolle Finit: Initialisierung des Puffers Fchgs: Einfügen/Aendern von Feldern im Puffer Kap

zeichner-Wert-Paare (<fname>,<value>) z.b.

19 Ausblick: Transaktionelle Message Queues für die Bankapplikation Client Queue ATM Queue Queue Transfer Bern Withdraw Zürich Credit DB DB Kap

20 Zielsystem tx_begin() Client tx_commit() Transfer ATM tpcall(char*) tpcall(char*) Debit EXEC SQL AT DB_NAME Bern Credit EXEC SQL AT DB_NAME Zürich Oracle Oracle Kap

Ähnliche Dokumente

Kap. 2.3 Infrastruktur durch Transaction Processing Monitore ( TP-Heavy ) Workshop

Kap. 2.3 Infrastruktur durch Transaction Processing Monitore ( TP-Heavy ) Workshop Vertiefung der X/Open DTP Protokolle Verteilte Transaktionsverarbeitung (i. vgl. zu Oracle) Optimierungen für 2PC Programmierparadigmen