Client/Server-Systeme Prof. Dr.-Ing. Wilhelm Spruth WS 2008/2009 Teil 8 Transaktionsverarbeitung cs 0800 ww6 sch 02-97 Literatur J. Gray, A. Reuter: „Transaction Processing“. Morgan Kaufmann, 1993. J. Horswill: „Designing and Programming CICS Applications“. O’Reilly, 2000 Mark Little, Jon Maron, Greg Pavlik: Java Transaction Processing : Design and Implementation Prentice Hall 2004, ISBN 0-13-035290-X css1152 ww6 wgs 06-97 Datenbanken Eine Datenbank besteht aus einer Datenbasis (normalerweise Plattenspeicher) und Verwaltungsprogrammen (Datenbank Software), welche die Daten entsprechend den vorgegebenen Beschreibungen abspeichert, auffindet, oder beliebige weitere Operationen mit den Daten durchführt. Wenn wir im Zusammenhang mit Client/Server Systemen von einer Datenbank sprechen meinen wir in der Regel damit die Verwaltungsprogramme (Datenbank im engeren Sinne). Ein Datenbankprozess läuft fast immer in einem eigenen virtuellen Adressenraum. Häufig sind es sogar mehrere virtuelle Adressenräume (z.B. drei im Fall von z/OS DB2). cs 2803 ww6 wgs 01-03 AnwendungsProzess DatenbankProzess z.B. Oracle, DB2 flat files (Dateien), z.B. VSAM PC Registrierkasse Geldausgabeautomat nicht relationale Datenbanken, z.B. ADABAS IMS relationale Datenbanken, z.B. DB2 UDB Ingress MS SQL mysql Oracle Sybase Datenbank Server in einer typische Client/Server Anwendung Logische Strukturen, als 2-Tier, 3-Tier oder n-Tier Konfigurationen bezeichnet, unterscheiden sich dadurch, wie die Funktionen Klient, Anwendungsprozess und Datenbankprozess auf physische Server abgebildet werden. Im einfachsten Fall (Beispiel Diplomarbeit) sind Anwendung und Datenbank getrennte Prozesse auf dem gleichen Rechner wie der Klient. cs 0859 ww6 wgs 12-99 Präsentation Business Logic DatenbankProzess z.B. Oracle, DB2 AnwendungsProzess PC Registrierkasse Geldausgabeautomat Typische Client/Server Anwendung Business Logic (Anwendungslogik) verarbeitet die Eingabedaten des Endbenutzers und erzeugt Ausgabedaten für den Endbenutzer, z.B. in der Form einer wenig strukturierten Zeichenkette. Präsentationslogik formt die rohen Ausgabedaten in eine für den Endbenutzer gefällige Form um. Anwendungsprozess und Datenbankprozess laufen in getrennten virtuellen Adressenräumen, ggf. auch auf getrennten physischen Servern. cs 2807 ww6 wgs 12-99 Traditionelle 3 Tier Client/Server Architektur Beispiel SAP/R3 Wiedergeburt des unintelligenten Klienten 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. Eine Transaktion ist die Zusammenfassung von mehreren Datei- oder Datenbankoperationen, die entweder erfolgreich abgeschlossen wird, oder die Datenbank unverändert läßt Die Datei/Datenbank bleibt in einem konsistenten Zustand: Entweder vor Anfang oder nach Abschluß der Transaktion Im Fehlerfall, oder bei einem Systemversagen werden alle in Arbeit befindlichen Transaktionen abgebrochen und alle evtl. bereits stattgefundenen Datenänderungen automatisch rückgängig gemacht. Wird eine Transaktion abgebrochen, werden keine Daten abgeändert cs1003 ww6 wgs 02-97 ACID Eigenschaften Atomizität (Atomicity) Konsistenzerhaltung (Consistency) Isolation Dauerhaftigkeit (Durability) Eine Transaktion ist eine Anwendung, welche die ACID Bedingungen erfüllz. cs 1024 ww6 wgs 03-98 x ACID Eigenschaften Atomizität (Atomicity) Eine Transaktion wird entweder vollständig ausgeführt oder überhaupt nicht Der Übergang vom Ursprungszustand zum Ergebniszustand erfolgt ohne erkennbare Zwischenzustände, unabhängig von Fehlern oder Crashes. Änderungen betreffen Datenbanken, Messages, Transducer und andere. Konsistenzerhaltung (Consistency) Eine Transaktion überführt die transaktionsgeschützten Daten des Systems von einem konsistenten Zustand in einen anderen konsistenten Zustand. Diese Eigenschaft garantiert, dass die Daten der Datenbank nach Abschluss einer Transaktion schemakonsistent sind, d. h. alle im Datenbankschema spezifizierten Integritätsbedingungen erfüllen Daten sind konsistent, wenn sie durch eine Transaktion erzeugt wurden. Isolation Die Auswirkungen einer Transaktion werden erst nach ihrer erfolgreichen Beendigung für andere Transaktionen sichtbar Single User Mode Modell. Selbst wenn 2 Transaktionen gleichzeitig ausgeführt werden, wird der Schein einer seriellen Verarbeitung gewahrt. Dauerhaftigkeit (Durability) Die Auswirkungen einer erfolgreich beendeten Transaktion gehen nicht verloren Das Ergebnis einer Transaktion ist real, mit allen Konsequenzen. Es kann nur mit einer neuen Transaktion rückgängig gemacht werden. Die Zustandsänderung überlebt nachfolgende Fehler oder Systemcrashes. cs 1024 ww6 wgs 03-98 Benutzer 1 Benutzer 2 Benutzer 3 .............. reduzieren Lager bestand Transaktions Verarbeitung Programm Benutzer n debit Debitoren Buchhaltung credit Kreditoren Buchhaltung Speichern / Drucken - Bestand nachbestellen Liefer Schein Audit Listen Fehler Berichte Beispiel für eine Transaktionsverarbeitungsanwendung: Auftragseingang-Bearbeitung cs 0809 ww wgs 01-99 Transactionssysteme Interaktive Beispiele: Auskunftsysteme Buchungssysteme (z.B. Flugplatzreservierung) Geldausgabeautomaten Auftragsbearbeitung, Buchbestellung bei Amazon Angebot bei eBay abgeben Stapelverarbeitung Beispiele: Monatliche Lohn/Gehaltsabrechnung Jährliche Bilanz erstellen Verkaufsabalyse oder Vertriebsstatistik erstellen In großen Systemen ist die Rechnerbelastung interaktiv zu Stapel etwa 60 : 40. css0117 ww6 wgs 05-98 Mehr als zwei Drittel aller in der Wirtschaft oder im öffentlichen Dienst durchgeführten Datenverarbeitungsvorgänge werden als Transaktionen ausgeführt und erfüllen die ACID Bedingungen. Typische Struktureines transaktionalen Programms start transaction if ok then commit else rollback commit bewirkt, dass die Datenbank in einen neuen konsistenten Zustand überführt wird. Statt rollback werden auch die Schlüsselworte abort oder backout verwendet. Wie schreibt man eine transaktionale Anwendung ? Drei Möglichkeiten 1. Man macht alles selber Sehr effektiv Sehr aufwendig Vermutlich 90 % des Codes beschäftigen sich mit der Einhaltung der ACID Bedingungen und der Fehlerbehandlung 2. Stored Procedures als Teil des Datenbankprozesses Für einfache Anwendungen 3. Transaktionsmonitor Frage: Wie verarbeitet der Server gleichzeitig Hunderte oder Tausende von Transaktionen ? Transaktionsmonitor Transaction Processing Monitor, TP Monitor Ein Transaktionsmonitor ist eine Laufzeitumgebung, welche den atomaren Charakter vieler gleichzeitig ablaufender Transaktionen sicherstellt. Zu den Kernfunktionen gehören: • • • • • • Message Queuing Lock Verwaltung Log Verwaltung 2-Phase Commit Synchronisation Rollback Funktion Laststeuerung (Load Balancing) Beispiele für Transaktionsmonitore BEA Tuxedo (AT&T→ →Novell → BEA) DEC ACMS für VMS, Ultrix IBM CICS IBM IMS-DB/DC IBM TPF SAP R/3 Siemens UTM Tandem NonStop Kernel (Guardian/Pathway) Microsoft Transaction Server (MTS) Corba OTS (Object Transaction Service) EJB JTS (Java Transaction Service) cs 0824 ww6 wgs 02-99 cs 0826a ww6 wgs 09-00 Komponenten eines TP Monitors Endbenutzer kommunizieren mit dem TP Monitor mit Hilfe von Nachrichten. Presentation Services bilden die Datenausgabe auf die GUI des Benutzers ab. Eingabe-Nachrichten werden mit einer trid (Transaktions ID) versehen und in einer Warteschlange gepuffert. Aus Zuverlässigkeitsgründen muß diese einen Systemabsturz überleben. Eine ähnliche Warteschlange existiert für die Ausgabe von Nachrichten. Der Scheduler verteilt eingehende Bearbeitungsanforderungen auf die einzelnen Server Prozesse. Ein TP Monitor bezeichnet seine Server Prozesse als Ressource Manager. Es existiert ein Ressource Manager pro (aktive) Anwendung. Ressource Manager sind multithreaded; ein spezifischer Ressource Manager für eine bestimmte Anwendung ist in der Lage, mehrere Transaktionen gleichzeitig zu verarbeiten. Der Lock Manager blockiert einen Teil einer Datenbanktabelle. In Zusammenarbeit mit dem Datenbanksystem stellt er die „Isolation“ der ACID Eigenschaft sicher. Der LOG Manager hält alle Änderungen gegen die Datenbank fest. Mit Hilfe der Log Datenbank kann der Recovery Manager im Fehlerfall den ursprünglichen Zustand der Datenbank wiederherstellen (Atomizität der ACID Eigenschaft). In dem Repository verwaltet der TP Monitor Benutzerdaten und -rechte, Screens, Datenbanktabellen, Anwendungen sowie zurückliegende Versionen von Anwendungen und Prozeduren. cs 0827 ww6 wgs 02-99 Fehlerbehandlung Fehlermöglichkeiten • Server kann Prozedur nicht beenden (z.B. Rechnerausfall, SW-Fehler) • Klient wird während des RPCs abgebrochen (z.B. Rechnerausfall, SW-Fehler) Im Gegensatz zum lokalen Prozeduraufruf sind Fehlerbehandlungsmaßnahmen erforderlich. cs 0311 ww6 Klient Server Fehler Fehler wgs 11-99 Fehlerbehandlung - Ausfall des Servers 1. Idempotente Arbeitsvorgänge "Idempotent" sind Arbeitsvorgänge, die beliebig oft ausgeführt werden können; Beispiel: Lese Block 4 der Datei xyz. Nicht idempotent ist die Überweisung eines Geldbetrages von einem Konto auf ein anderes. 2. Nicht-idempotente Arbeitsvorgänge Problem: Wie wird festgestellt, ob Arbeitsgang durchgeführt wurde oder nicht. "Genau einmal" (exactly once). Überweisung Konto x y "Höchstens einmal" (at most once). Stimmabgabe Bundestagswahl "Wenigstens einmal" (at least once). Ideal für idempotente Vorgänge. Update Virenscanner css0407 ww6 sch 10-96 Eingabe Queue enqueue dequeue Queue Verarbeitung Manager Transaktions Klient dequeue enqueue Ausgabe Queue Server Queue Manager Jede einzelne Transaktion wird in 3 Subtransaktionen aufgelöst, die alle eigene ACID Eigenschaften haben. Subtransaktion 1 nimmt die Eingabenachricht entgegen, stellt sie in die Eingabe Queue, und commits. Subtransaktion 2 dequeues die Nachricht, verarbeitet sie, stellt das Ergebnis in die Ausgabequeue, löscht den Eintrag in der Eingabequeue und commits. Subtransaktion 3 übernimmt das Ergebnis von der Ausgabequeue, übergibt das Ergebnis an den Klienten, löscht den Eintrag in der Ausgabequeue und commits. Ein separater Queue Manager ist optimiert für diese Aufgabe. es 1159 wgs 08-00 TP Repository Andere Bezeichnung: Katalog, Dictionary Katalogisiert: Benutzer Workstation IDs (Terminal IDs) Screens Anwendungen Prozeduren Tabellen Z.B. Hinzufügen eines Feldes in einen Screen ändert Client Software, Server Schnittstelle, fügt eine weitere Spalte in eine SQL Tabelle ein, .... SABRE Flugplatzreservierungssystem zentraler Verarbeitungsablauf cs 0922 ww6 wgs 0923 07-00 Backward Recovery Der Transaktionsmonitor stellt sicher, daß im Fehlerfall der teilweise Ablauf einer Transaktion rückgängig gemacht wird, und daß alle abgeänderten Felder einer Datenbank wieder in ihren ursprünglichen Zustand zurückbersetzt werden. Andere Bezeichnungen: • backout • rollback • abort cs1026 ww6 wgs 02-97 Plattenspeicher Zwischenpuffer In LOG File übernehmen, dann löschen 5 1 1 4 3 2 ack 2 commit abzuändernde Datensätze zu schreibende Daten Hauptspeicher Backward Recovery Andere Bezeichnungen: backout, roll back abort 1. abzuändernde Information in Puffer zwischenspeichern 2. Datensätze überschreiben 3. Commit Status festhalten. Damit ist es geschehen 4. erfolgreiches Commit dem Benutzer mitteilen 5. Zwischenpuffer löschen css1010 ww6 wgs 02-97 Log File Konzept Das Log ist eine historische Aufzeichnung aller Änderungen des Zustands (state) des Systems. Das Log ist eine sequentille Datei. Das vollständige Log enthält die historische Entwicklung aller Datenbankänderungen. Log + alter Zustand ergibt neuen Zustand. Beim „Commit“ einer Transaktion wird das Log persistent gespeichert (z.B. auf einer gespiegelten Platte). Log wird zur Wiederherstellung einer Transaktion im Falle eines Fehlers benutzt: • System failure: lost in-memory updates • Media failure (lost disk) Bewirkt die Dauerhaftigkeit (Durability) einer Transaktion. Flat Transaction start_transaction { beginwork ( ); ..... ..... ..... ..... ..... ..... ..... ..... if no_error commit ( ) else rollback ( ) ; } cs 0822 ww6 rahm 02-99 Transaction #1 Begin Trans. Transaction #2 Begin Trans. Commit Transaction #3 Begin Trans. Commit Commit t Flat Transaction Alle Arbeit innerhalb einer Flat Transaction findet auf der gleichen Ebene statt. Die Transaktion überlebt entweder mit allen Teilfunktionen (commit) oder es erfolgt ein rollback einschließlich aller Teilfunktion (abort). start_transaction { beginwork( ); ..... ..... ..... ..... if no_error commit( ) else rollback( ) ; cs 0855 ww wgs 12-99 Logical Unit of Work LUW Aktion 1 Aktion 2 Aktion 3 Aktion 4 Aktion 5 Aktion 6 Start Transaktion Ende Transaktion LUW 4 LUW 3 LUW 2 LUW 1 Aktionen sind Bausteine, aus denen der (zeitliche) Arbeitsablauf eines Resource Managers (Server) besteht. Nicht geschützte (unprotected) Aktionen haben keine ACID Eigenschaften. Geschützte (protected) Aktionen haben ACID Eigenschaften und werden als „Logical Unit of Work“ (LUW) bezeichnet. Teilweise abgeschlossene LUW´s können rückgängig gemacht werden. Reale (real) Aktionen beeinflussen die physikalische Umwelt auf eine Art, die nur schwer oder garnicht rückgängig zu machen ist (roll back). Beispiele: Ein Loch bohren, Geldausgabe am Automaten, vertrauliche Daten an den falschen Empfänger senden. ACID Eigenschaften für reale Aktionen mögen schwierig oder unmöglich zu implementieren sein. cs 0842 ww6 wgs 05-97 LUW Transaktion A Start der Transaktion LUW LUW Ende der Transaktion (Syncpoint) LUW Transaktion B Start der Syncpoint Syncpoint Transaktion LUW Syncpoint Ende der Transaktion (Syncpoint) „Logical Units of Work „ (LUW) und Syncpoints Andere Bezeichnungen für Syncpoints: Commit points bzw. Save Points Syncpoints bewirken, dass BACKOUT bzw. ROLLBACK die Transaktion nur bis zu dem letzten, erfolgreich abgeschlossenen Syncpoint zurücksetzt. cs 0903 ww wgs 02-97 Sync Points Sync points are logical points in the program execution and delimit a logical unit of work (LUW). A logical unit of work is a logical sequence of processing actions (for example, database changes) that must be completed before any of the actions of the sequence can be seen as committed. Sync points occur where the changes being made are consistent and complete, and can then be committed to the database. After a sync point is reached: Held output is sent to its destination Input is removed from message queues Database updates are made available to other applications One task may equal one LUW with no sync point, but most complex tasks have several sync points. When there is an abnormal termination, the transaction monitor recovery and restart facilities do not back out program updates before the last completed sync point. t LUW Rollback cs 0905 ww wgs 02-97 1.Darlehnskonto abrechnen, Saldo um Tilgungsrate verändern 2.Tilgung und Zinsen im laufenden Konto (Kontokorrent) auf der Sollseite buchen 3.Globales Limit überprüfen 4.Bilanzpositionen (Konten) 5.G+V Positionen (Gewinn- und Verlust Konten) 6.Zinsabgrenzung monatlich für jährliche Zinszahlung 7.Bankmeldewesen (ein Kunde nimmt je 90 000.- DM bei 10 Banken auf, läuft am Stichtag) 6 7 1 2 3 4 5 6 7 1 2 3 Zeit Abarbeitung in Reihenfolge evt. keine Sync Points erforderlich cs 0898 ww6 wgs 12-99 Buchungsvorgänge, monatliche Kreditabrechnung 1. Darlehnskonto abrechnen, Saldo um Tilgungsrate verändern 2. Tilgung und Zinsen im laufenden Konto (Kontokorrent) auf der Sollseite buchen 3. Globales Limit überprüfen 4. Bilanzpositionen (Konten) 5. G+V Positionen (Gewinn- und Verlust Konten) 6. Zinsabgrenzung monatlich für jährliche Zinszahlung 7. Bankmeldewesen (ein Kunde nimmt je 90 000.- DM bei 10 Banken auf, läuft am Stichtag) Buchungsvorgang 1 2 3 4 5 6 7 Kunde Nr 1 2 3 . Beispiel: Schritte 1 - 3 als 1 Transaktion Schritte 4 - 7 : Zwischenergebnisse persistent speichern . 99999 cs 0879 ww6 wgs 12-99 Main Transaction von Konto 1 abbuchen auf Konto 2 zubuchen Zeit update history start transaction 2 phase commit TP Monitor Oracle Database TP Monitor DB2 Database TP Monitor Sybase Database Distributed Flat Transaction cs 0853 ww6 wgs 12-99 Zwei-Phasen-Festübergabe Two-phase Commit Erforderlich bei der gleichzeitigen Änderung mehrerer Datenbanken, z.B. Banküberweisung von Bank A nach Bank B Elektronisches Clearinghaus sendet Nachrichten an beide Banken Problem, wenn entweder Abbuchung oder Gutschrift nicht erfolgt Daher atomare Transaktionen erforderlich Konsistenz wird erreicht durch einen „Master“ (Commit-Koordinator), der die Arbeit von „Slaves“ überwacht Clearinghaus übernimmt Rolle des Master, die beiden Banken sind Slaves. Two-phase-Commit-Protokoll stellt sicher, daß Abbuchung und Gutschrift entweder beide erfolgen, oder beide nicht erfolgen Slave #1 Slave #2 Datenbank A Abbuchung Konto Nr. xxx Datenbank B Gutschrift Konto Nr. yyy Commit Coordinator Master css1011 ww6 wgs 02-97 2-Phase Commit Protokoll cs 0953 ww 6 wgs 12-04 Master Slave Begin atomic action Send Request 1 ............. Send Request n Send „ Prepare to commit“ if action can be performed then begin Lock data Store initial state on disk Store requests on disk Send „OK“ end else Send „Failure“ if all slaves said „OK“ then send „Commit“ else send „Rollback“ Wait for acknowledgements if master said commit then begin Do work Unlock data Send „Acknowledgement“ 2-Phase Commit Protokoll cs 0938 ww6 nach Tanenbaum wgs 12-01 Anwendungen API Transaction Processing Monitor Database Management System DBI Kernel Unabhängiger Transaktionsverarbeitungs-Monitor TP Monitor und Datenbank-System laufen in getrennten virtuellen Adressenräumen Beispiele : CICS, SAP R/3 Anwendungen API Transaction Processing Database Management Kernel Transaktionsmonitor und Datenbank-System sind in den Kernel integriert Beispiel: TPF Betriebssystem-Schnittstelle cs 0906 ww wgs 02-97 Implementierung eines Transaktionsmonitors Operationen über Adressraumgrenzen hinweg benötigen Millisekunden Operationen im gleichen Adressraum benötigen Mikrosekunden-Bruchteile Ein Faktor 10000 Geschwindigkeitsunterschied ist möglich Bei der IBM TPF (Transaktion Processing Facility, ehemals ACP und SABRE) laufen Anwendungen, Transaktionsmonitor und Überwacher gemeinsam alle im Überwacherstatus css1008 ww6 wgs 02-97 IBM Transaction Processing Facility TPF Eigenständiges Betriebssystem, erlaubt nur eine einzige Anwendung: Transaktionsverarbeitung Hervorgegangen aus dem SABER (SABRE) Flugplatzreservierungs-system (American Airlines, 1959). Später umbenannt in SABRE → ACP → TPF Keine Einrichtungen für Softwareentwicklung (erfolgt auf einem anderen Rechner) Run-to-Completion (non-preemptive) Scheduler/Dispatcher Betriebssystem Aufruf erfordert ca. 500 Maschinenbefehle E/A Operation erfordert etwa 500 - 800 Maschinenbefehle > 10000 Transaktionen/s Anwendungen: Flugplatzreservierung (Amadeus) Geldausgabeautomaten Kreditkartenverifizierung Transaction Processing Facility TPF 13. Oktober 2006. Die Firma Worldspan, ein weltweiter Anbieter von Reise-Reservierungs-systemen, hat sich für den Einsatz von sechs IBM System z9 Enterprise Class (EC) Mainframe-Servern entschieden. Worldspan will damit sein Angebot an elektronischen Datendiensten erweitern, um circa 700 Anbietern von Reiseangeboten und Millionen von Reisenden weltweit eine gemeinsame Plattform anbieten zu können. Worldspan setzt die neuen Server ein, um sowohl Reisebüros als auch Anbietern von Online-basierten Reisediensten die Möglichkeit zur Nutzung des weltweiten Global Distribution System (GDS) zu geben, über das zum Beispiel die Bestellung und Buchung von Reiseprodukten von Flugzeugtickets, Hotels, Mietwagen und andere Reisedienst-leistungen durchgeführt wird. Durch die Nutzung der Software „IBM Transaction Processing Facility“ (TPF) ist Worldspan in der Lage, 17.000 Kundenanfragen pro Sekunde auf den Mainframes zu beantworten.