6. Transaktionskonzept: Weiterentwicklungen

Transkript

1 6. Transaktionskonzept: Weiterentwicklungen Beschränkungen flacher Transaktionen Rücksetzpunkte (Savepoints) (Geschlossen) Geschachtelte Transaktionen Konzept Sperrverfahren Offen geschachtelte Transaktionen Mehrebenen-Transaktionen Transaktionsketten (Sagas) Transaktionen in Workflows / Geschäftsprozessen ConTracts WebService Transaktionen (BPL / Biztalk / WS-Transactions) Lange ntwurfstransaktionen 6-1 Beschränkungen flacher Transaktionen: nwendungsbeispiele CID auf kurze Transaktionen zugeschnitten, Probleme mit "lang-lebigen" ktivitäten (long-lived transactions) lange Batch-Vorgänge (Bsp.: Zinsberechnung) lles-oder-nichts führt zu hohem Verlust an rbeit insatz vieler unabhängiger Transaktionen verlangt manuelle Recovery-Maßnahmen nach Systemfehler Workflows Bsp.: mehrere Reservierungen für Dienstreise lange Sperrdauer führt zu katastrophalem Leistungsverhalten (Sperrkonflikte, Deadlocks) Rücksetzen der gesamten ktivität im Fehlerfall i.a. nicht akzeptabel ntwurfsvorgänge (CD, CS,...) lange Dauer von ntwurfsvorgängen (Wochen/Monate) kontrollierte Kooperation zwischen mehreren ntwerfern Unterstützung von Versionen 6-2

2 Beschränkungen flacher Transaktionen lles-oder-nichts-igenschaft oft inakzeptabel: hoher rbeitsverlust höhere Wahrscheinlichkeit, durch Systemfehler zurückgesetzt zu werden Isolation Leistungsprobleme durch "lange" Sperren Sperren vieler Objekte rhöhung der Blockierungsrate und Konfliktrate höhere Rücksetzrate (Deadlock-Häufigkeit stark abhängig von der Größe der Transaktion) fehlende Unterstützung zur Kooperation keine Binnenstruktur fehlende Kapselung und Zerlegbarkeit von Teilabläufen keine abgestufte Kontrolle für Synchronisation und Recovery keine Unterstützung zur Parallelisierung fehlende Benutzerkontrolle 6-3 Partielles Zurücksetzen von Transaktionen Voraussetzung: private Rücksetzpunkte (Savepoints) innerhalb einer Transaktion T 1 T 11 T 12 T 13 T 14 T 15 T 1n R (0) R (1) R (2) R (k) = Transaktionsschritt R(i) = i-ter Rücksetzpunkt Operationen: SVPOINT R(i) ROLLBCK TO SVPOINT R(j) Protokollierung aller Änderungen, Sperren, Cursor-Positionen etc. notwendig Partielle UNDO-Operation bis R(i) in LIFO-Reihenfolge Problem: Savepoints werden vom Laufzeitsystem der Programmiersprachen nicht unterstützt nmerkung: Savepoints sind keine Checkpoints 6-4

3 SQL-Transaktionsanweisungen Savepoints in SQL:1999 STRT TRNSCTION [RD { ONLY WRIT } ] [ISOLTION LVL { RD UNCOMMITTD RD COMMITTD RPTBL RD SRILIZBL } ] ST TRNSCTION [RD { ONLY WRIT } ] [ISOLTION LVL {... } ] ST CONSTRINTS { LL <Liste von Int.beding.>} {IMMDIT DFRRD} COMMIT [WORK] [ND [NO] CHIN] SVPOINT <Rücksetzpunktname> RLS SVPOINT <Rücksetzpunktname> ROLLBCK [WORK] [ND [NO] CHIN] [TO SVPOINT <Rücksetzpunktname>] Beispiel INSRT INTO Pers (PNR, Name, Gehalt) VLUS (1234, Schulz, 40000); INSRT INTO Pers (PNR, Name, Gehalt) VLUS (1235, Schneider, 38000); SLCT SUM (Gehalt) INTO Summe FROM Pers; IF Summe > THN ROLLBCK; LS SVPOINT R1; INSRT INTO Pers (PNR, Name, Gehalt) VLUS (1300, Weber, 39000);... IF... THN ROLLBCK TO SVPOINT R1; 6-5 Seit JDBC 3.0 Methoden (Klasse Connection) setsavepoint (savepointname) releasesavepoint (savepoint) rollback (savepoint) Beispiel Savepoints in JDBC try { // Verbindungsobjekt conn sei gegeben conn.setutocommit(false); Statement stmt = conn.createstatement(); String SQL = "INSRT INTO Pers VLUS (106, 20, 'Rita', 'Tez')"; stmt.executeupdate(sql); Savepoint savepoint1 = conn.setsavepoint("savepoint1"); String SQL = "INSRTD IN Pers VLUS (107, 22, 'Sita', 'Tez')"; //fehlerhaftes SQL stmt.executeupdate(sql); conn.commit(); } catch(sqlxception se) { conn.rollback (savepoint1); } 6-6

4 Geschachtelte Transaktionen (nested transactions) Zerlegung einer Transaktion in eine Hierarchie von Sub- Transaktionen Zerlegung erfolgt anwendungsbezogen, z.b. gemäß Modularisierung von nwendungsfunktionen Transaktionsbaum verdeutlicht statische ufrufhierarchie H B G I C F D ausgezeichnete Transaktion = Top-Level Transaction (TL) Bewahrung der CID-igenschaften für TL-Transaktion Welche igenschaften gelten für Sub-Transaktionen? 6-7 Transaktionseigenschaften K B I L C H D F G Kontrollbereich von C Commit-Regel: Das (lokale) Commit einer Sub-Transaktion macht ihre rgebnisse nur der Vater-Transaktion zugänglich. Das endgültige Commit der Sub-Transaktion erfolgt dann und nur dann, wenn für alle Vorfahren bis zur TL-Transaktion das endgültige Commit erfolgreich verläuft. Rücksetzregel: Wenn eine (Sub-) Transaktion auf irgendeiner Schachtelungsebene zurückgesetzt wird, werden alle ihre Sub-Transaktionen, unabhängig von ihrem lokalen Commit-Status ebenso zurückgesetzt. Diese Regel wird rekursiv angewendet. Sichtbarkeits-Regel: Änderungen einer Sub-Transaktion werden bei ihrem Commit für die Vater-Transaktion sichtbar. Objekte, die eine Vater-Transaktion hält, können Sub-Transaktionen zugänglich gemacht werden. Änderungen einer Sub-Transaktion sind für Geschwister-Transaktionen nicht sichtbar. 6-8

5 igenschaften von Sub-Transaktionen : erforderlich wegen Zerlegbarkeit, isoliertes Rücksetzen, usw. C: zu strikt; Vater-Transaktion (spätestens TL-Transaktion) kann Konsistenz wiederherstellen I: erforderlich wegen isolierter Rücksetzbarkeit usw. D: nicht möglich, da Rücksetzen eines äußeren Kontrollbereichs das Rücksetzen aller inneren impliziert 6-9 Geschachtelte Transaktionen: Sperrverfahren Sperren bei flachen Transaktionen: rwerb gemäß Kompatibilitätsmatrix (z.b. Halten von R- und X-Sperren) Freigabe bei Commit Unterscheidung zwischen gehaltenen (X- und R-) Sperren und von Sub-Transaktionen geerbten Platzhalter-Sperren (retained locks) r-x und r-r r-x: nur Nachfahren im Transaktionsbaum (und Transaktion selbst) können Sperren erwerben r-r: keine X-Sperre für Vorfahren im Transaktionsbaum sowie andere (unabhängige) Transaktionen 6-10

6 Regeln zum Sperren geschachtelter Transaktionen R1: Transaktion T kann X-Sperre erwerben falls keine andere Transaktion eine X- oder R-Sperre auf dem Objekt hält, sowie alle Transaktionen, welche eine r-x oder r-r-sperre besitzen, Vorfahren von T sind (bzw. T selbst) R2: Transaktion T kann R-Sperre erwerben falls keine andere Transaktion eine X-Sperre hält, sowie alle Transaktionen, welche eine r-x besitzen, Vorfahren von T sind (bzw. T selbst) R3: Beim Commit von Sub-Transaktion T erbt Vater von T alle Sperren von T (reguläre + retained-sperren). Für reguläre Sperren von T werden beim Vater die entsprechenden retained-sperren gesetzt R4: Beim bbruch einer Transaktion T werden alle regulären und Platzhalter- Sperren von T freigegeben. Sperren der Vorfahren bleiben davon unberührt Geschachtelte Transaktionen: Sperrverfahren (2) a) Lese-Szenario B B B R C D R R-lock commit C D commit R-lock B R-lock D b) Änderungs-Szenario B B B B X C D commit C R-lock D commit R-lock D D commit D R-lock B 6-12

7 a) Geschachtelte Transaktionen: Sperrverfahren (3) r-x X-Sphäre R-Sphäre b) X-Retain-Sperre für r-x R-lock commit X-lock commit X-Retain-Sperre für 6-13 Geschachtelte Transaktionen: Sperrverfahren (4) Beschränkungen des vorgestellten Sperrverfahrens Sub-Transaktionen können keine Objekte lesen oder ändern, die von einem Vorfahren geändert wurden Sub-Transaktionen können keine Objekte ändern, die von einem Vorfahren gelesen wurden bhilfe: Unterstützung von ufwärts- und bwärts-vererbung von Sperren bei Sperrkonflikt zwischen Sub-Transaktion und Vorfahr kann Vorfahr Sperre an Sub- Transaktion vererben (downward inheritance) Vorfahr reduziert seine Sperre auf Platzhalter-Sperre X commit X-Sperre für X-lock 6-14

8 Vorteile Merkmale geschlossen geschachtelter Transaktionen explizite Kontrollstruktur innerhalb von Transaktionen Unterstützung von Intra-Transaktionsparallelität Unterstützung verteilter Systemimplementierung feinere Recovery-Kontrolle innerhalb einer Transaktion Modularität des Gesamtsystems einfachere Programmierung paralleler bläufe CID für Wurzel-Transaktionen lässt Hauptprobleme flacher Transaktionen ungelöst tomarität gegenüber Systemfehlern Isolation zwischen Transaktionen 6-15 Geschachtelte Transaktionen in SQL-Server Commit/Rollback äußerer Transaktionen wird auf innere Transaktionen propagiert Commit innerer Transaktionen wird ignoriert Commit Transaction/ Commit Work bezieht sich auf letztes Begin Transaction Rollback in innerer Transaktion führt zum bbruch der gesamten geschachtelten Transaktion 6-16

9 Beispiel SQL-Server 6-17 Offen geschachtelte Transaktionen (open nested transactions) Freigabe von Ressourcen (Sperren) bereits am nde von Sub- Transaktionen - vor bschluss der Gesamttransaktion Ziel: Lösung des Isolationsproblems langlebiger Transaktionen verbesserte Inter-Transaktionsparallelität (neben Intra-Transaktionsparallelität) Probleme hinsichtlich Synchronisation sowie Recovery Synchronisationsprobleme Sichtbarwerden "schmutziger" Änderungen verletzt i.a. Serialisierbarkeit dennoch werden oft mit der Realität verträgliche bläufe erreicht ggf. insatz semantischer Synchronisationsverfahren 6-18

10 Offene Schachtelung (2) vorzeitige Freigabe von Änderungen erfordert kompensationsbasierte Undo-Recovery zustandsorientierte Undo-Recovery nicht möglich -> logische Kompensation ( semantisches Zurücksetzen) Kompensationen sind auch in der Realität verbreitet (Stornierung, Terminabsage,...) Probleme kompensationsbasierter Recovery Korrektheit der Kompensationsprogramme Kompensationen dürfen nicht scheitern nicht alle Operationen sind kompensierbar (z.b. "real actions" mit irreversiblen uswirkungen) 6-19 Mehrebenen-Transaktionen (multi-level transactions) Schachtelung von Transaktionen längs der bbildungshierarchie von Schichtenarchitekturen Transaktionsverwaltung auf jeder bene vorzeitiges Commit (Freigabe von Änderungen/Sperren) von Sub- Transaktionen offen geschachtelte Transaktionen aber: Schutzschirm auf höherer bene bleibt erhalten reduzierte Konfliktgefahr zwischen Transaktionen unter Wahrung von Serialisierbarkeit Transaktionsabbruch erfordert Kompensation bereits beendeter Sub- Transaktionen 6-20

11 Mehrebenen-Transaktionen (2) Verallgemeinerung auf beliebige Schichten/Operationen möglich Nutzung von nwendungssemantik zur Synchronisation möglich theoretisch fundierter nsatz potentiell hoher ufwand zur Transaktionsverwaltung, insbesondere für Logging und Recovery für Gesamt-Transaktion gelten weiterhin CID-igenschaften 6-21 Das Konzept der Sagas Saga langlebige Transaktion, die in eine Sammlung von Sub- Transaktionen aufgeteilt werden kann T spezielle rt von zweistufigen, offen geschachtelten Transaktionen BOS T 1 T 2 T 3... T n OS T i geben Ressourcen vorzeitig frei Verzahnung mit T j anderer Transaktionen (Sagas) keine Serialisierbarkeit der Gesamt-Transaktion (Saga) Rücksetzen von Sub-Transaktionen durch Kompensation alle T i gehören zusammen; keine teilweise usführung von T Bereitstellung von Kompensationstransaktionen C i für jede T i 6-22

12 Sagas (2) Zusicherung des DBS 1. T 1, T 2, T 3,..., T n oder 2. T 1, T 2,..., T j, C j,..., C 2, C 1 für irgendein 0 j < n Backward Recovery: LIFO-usführung der Kompensationen Kompensationen dürfen nicht scheitern Saga-bbildung in Workflow: 6-23 Sagas (3) Backward-Revovery vielfach unerwünscht, v.a. nach Systemfehler Unterstützung von Forward-Recovery durch (persistente) Savepoints Partielles Rücksetzen möglich: Kombination von Backward- und Forward-Recovery Szenario: Savepoint nach T 2 Crash nach T 4 blauf: BS, T 1, T 2, SP, T 3, T 4, Zusammenfassung der igenschaften: +I für jede Sub-Transaktionen T i +C+D für Saga (umfassende Transaktion T) 6-24

13 Sagas: Backward vs. Forward Recovery Transaktionsunterstützung für Business-Prozesse Saga-Modell zu einfach für reale Workflows / Business-Prozesse Komplexe Interaktionen zwischen Teilsystemen (unterschiedliche Datenhaltungssysteme / Organisationen) Komplexe blauflogik (nicht nur Sequenz) Notwendigkeit Kontext zwischen Schritten persistent zu halten Notwendigkeit einer anwendungsbezogenen Fehler- bzw. usnahmebehandlung Nutzung standardisierter Kommunikations- und Koordinationsprotokolle Web Services Business Process xecution Language (WS-BPL) Transaktionsspezifikationen: WS-Transactions BPL-Unterstützung in zahlreichen service-basierten pplikationsumgebungen MS Biztalk, IBM Websphere, SP Netweaver, Oracle, B, jboss 6-26

14 ConTracts ConTract-Modell: Mechanismus zur kontrollierten und zuverlässigen usführung langlebiger ktivitäten zweistufiges Programmiermodell: Trennung nwendungsentwicklung von Beschreibung der blaufstruktur Skript: Beschreibung der blaufstruktur / Kontroll- und Datenfluss (Workflow-Definition) Steps: Programmierung der elementaren Verarbeitungsschritte der nwendung + Kompensationsaktion Step ist sequentielles Programm, z.b. CID-Transaktion Zentrale Konsistenzeigenschaft: ein ConTract terminiert in endlicher Zeit und in einem korrekten ndzustand auch bei Systemfehler Fortsetzung der Verarbeitung nach vorne oder kontrollierte Zurückführung eines ConTracts auf seinen nfangszustand 6-27 Beispiel-Workflow S 6 bbruch S 3 Fehler S 5 S 1 S 2 S 3 S4 Fehler S 5 S 7 C 1 C 2 S 3 Flugstatus zeigen Flugreservierung Hotelinfo Hotelreservierung Leihauto Dokumente drucken 6-28

15 ConTracts (Forts.) rweiterungen gegenüber Saga-nsatz reichere Kontrollstrukturen (Sequenz, Verzweigung, Parallelität, Schleife, etc.) getrennte Beschreibung von Steps und blaufkontrolle (Skript) Verwaltung eines persistenten Kontextes für globale Variablen, Zwischenergebnisse, Bildschirmausgaben, etc. Synchronisation zwischen Steps über Invarianten flexible Konflikt-/Fehlerbehandlung Transaktionsübergreifende Kontrolle der Vearbeitung Synchronisation Recovery Kontext 6-29 Synchronisation von Contracts Synchronisation mit Invarianten: semantische Synchronisationsbedingungen für korrekte Step-usführung Wenig Behinderungen: hohe Parallelität usschluss von Konsistenzverletzungen trotz frühzeitiger Sperrfreigabe Invarianten steuern die Überlappung parallel ablaufender ConTracts bzw. Steps über Prädikate (keine Serialisierbarkeit) usgangs-invarianten charakterisieren den am nde eines Steps erreichten Zustand der bearbeiteten Objekte Folge-Step kann mit seiner ingangs-invarianten überprüfen, ob die Bedingung für seine korrekte Synchronisation noch erfüllt ist Realisierung mit Check/Revalidate-nsatz Real ctions können nicht über Invarianten synchronisiert werden # frei > 1 # frei > 1 Flugauskunft Flugbuchung 6-30

16 Web Service Standards für SO Discovery, Negotiation, greement UDDI, WS-ddr, Metadata xch., Composite Interface+Bindings XML WS-BPL Orchestration Reliable Messaging WS-RM WS-C WS-N WSDL Component Model SC WS-Security Policy State tomic Security Protocols Transactions WS-RF WS-Policy WS-T WS-B SOP, WS-ddr Non-XML JMS, RMI/IIOP,... Components Quality of Service Description Messaging Transport HTTP, TCP/IP, SMTP, FTP, Transport 6-31 Business-Prozesse: Orchestration vs Choreography Zentralisierter nsatz regelt Interaktion zwischen Services Interaktion betrifft Nachrichtenaustausch, blauflogik und blaufreihenfolge Interagierende Komponenten wissen nichts voneinander Komplexe Interaktionsmuster Interagierende Komponenten wissen voneinander Choreography soll allgemeine Regeln und zwischen Partnern vereinbarte Kooperationsmuster nutzen [W3C] 6-32

17 WS-BPL Prozesse Process Partner Links Variables Correlation Sets Fault Handlers Compensation Handlers Receive vent Handlers ctivities Invoke Reply Festlegung von Schnittstellen und Nachrichtenformaten lokalen Variablen (Kontext) Identifikation Service-Instanz (Correlation Sets) usnahmebehandlung Kompensationen (z.b. auf Basis von WS-Businessctivities) ktivitäten regeln usführungsreihenfolge involvierter Web-Services BPL-Prozess wird selbst als Web Service repräsentiert rekursive Nutzung von Web-Services zur Definition von Geschäftsprozessen (Komposition von Web-Services) 6-33 Beispiel BPL-Prozess Verwendung von durch Partner bereitgestellter Services im Rahmen neuer Services Interfaces exposed by the BPL process Interfaces consumed by the BPL process WSDL Loan pproval PortType Loan pproval Process receive invoke Financial Institution s Web Service (Loan pprover) reply Web Service Web Service 6-34

18 Transaktionen in Biztalk Realisierung bereits in XLNG-Sprache (Vorläufer von BPL) GUI zur Definition der Prozesse Long Running (L-R) Transaktionen und atomare Transaktionen (Scopes) Compensation Handler pro atomarer Transaktion nwendung in umfassender L-R-Transaktion im Rahmen des xception Handling Default-Fehlerbehandlung: Backward Recovery über Compensation Handler Besonderheiten (Forward Recovery) Retry für tomic Tx möglich Manuelles Zurückgehen auf Persistence Points (Savepoints), die nach tomic Tx gsetzt werden Transaktionen in Biztalk (2) Schachtelung von L-R und tomic Tx tomic Tx können als Leave-Knoten auftreten Fehlerbehandlung jeweils auf nächsthöherer bene 6-36

19 WS-Transactions OSIS-Standard seit 2005 Drei Teile WS-Coordination + WS-tomicTransaction (T) WS-Businessctivity (B) WS-Coordination (WS-C) Koordinierung der Transaktions/Prozess-Beendigung Unterschiedliche Transaktionskonzepte / Commit-Protokolle dazu nutzbar (inkl. selbst definierten) Spezifikationen für ctivation Service (Festlegung Koordinator und Protokoll), Registration Service (für neue Teilnehmer), Completion Service (Durchführung des gewählten Koordinierungsprotokolls) 6-37 WS-tomicTransaction verteilte CID-Transaktionen mit mehreren Services verteiltes 2-Phase-Commit (2PC) für lles-oder-nichts Serialisierbarkeit (lange Sperren) etc. v.a. sinnvoll innerhalb einer Organisation tomic transaction Web service WSa Web service WSb Transaction Manager 2PC RDBMS 2PC RDBMS 2PC Transaction Manager pp Server 1 pp Server

20 WS-Businessctivities v.a. für Prozesse zwischen verschiedenen Organisationen Ähnliche Merkmale wie für L-R-Transaktionen in Biztalk kompensationsbasiertes Zurücksetzen einzelner Services / ktvitäten keine Sperren über Services hinweg Schachtelung von ktivitäten (Scopes) möglich Persistierung des Prozess-Zustandes nach usführung von ktivitäten Business ctivity Compensate Compensate B participant B participant Business Task Web service WSa Web service WSb Business Task Runtime 1 Runtime DB-Verarbeitung in ntwurfsumgebungen Workstation Tools Tools Tools WDBMS WDBMS WDBMS private DB Merkmale Workstation/Server-rchitektur lange Dauer von ntwurfsvorgängen (Wochen/Monate) Server SDBMS Benutzerkontrolle (nicht-deterministischer blauf) kontrollierte Kooperation zwischen mehreren ntwerfern Unterstützung von Versionen Lösungsansätze: Checkout/Checkin-Modell transaktionsinterne Savepoints public DB vorzeitiger ustausch von Änderungen zwischen Designern 6-40

21 ntwurfstransaktion bei Workstation/ Server-Kooperation ntwurfstransaktion STRT ND rbeitsplatzrechner SV lokale Verarbeitung lokale Verarbeitung Checkout 1 Checkout 2 Checkout 3 SUSPND RSUM RSTOR lokale Verarbeitung Isolation von ntwurfsobjekt 1 Isolation von ntwurfsobjekt 2 Isolation von ntwurfsobjekt 3 Server Charakteristika: 0.. n Checkout-, Checkin-Vorgänge, lange Dauer Speicherung von Zwischenzuständen einer ntwurfstransaktion zum: Unterbrechen der Verarbeitung (SUSPND, RSUM) Rücksetzten auf frühere Verarbeitungszustände (SV, RSTOR) 6-41 Zusammenfassung CID verbreitet und bewährt, hat jedoch Beschränkungen Geschlossen geschachtelte Transaktionen Unterstützung von Intra-Transaktionsparallelität feinere Rücksetzeinheiten v.a. in verteilten Systemen wichtig Offen geschachtelte Transaktionen (z.b. Sagas) Unterstützung langlebiger Transaktionen Reduzierung der Konfliktgefahr durch vorzeitige Sperrfreigabe Backward-Recovery durch Kompensation Forward-Recovery erforderlich Service-basierte Business-Prozesse langlebige Transaktionen mit kompensierbaren CID-Services standardisierte Protokolle (WS-Transactions) Unterstützung langer ntwurfstransaktionen zugeschnittene Verarbeitungsmodelle (Checkout/Checkin) Kooperation innerhalb von Transaktionen Unterstützung von Versionen und Savepoints 6-42