Transaktionsabwicklung in SQL-DB-Servern

1. Transaktionsabwicklung in SQL-DB-Servern Vortrag von Michael Sand, MA

2. Gliederung • Abgrenzung des Themas • Motivation • Problemstellung • Was ist Konsistenz? • Was ist eine Transaktion? • ACID-Eigenschaften • Nebenläufigkeit: Concurrency • Ansätze: pessimistisch vs. optimistisch • Transaktionalität auf Applikationsebene • Transaktionssicherung durch das DBMS • Ausblick: Interaktion zwischen Systemen

3. Abgrenzung des Themas Transaktionen in SQL-Datenbanken Transaktionen zwischen Systemen TP Heavy Transaktionen in Applikationen TP Lite Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung Motivation Fehlerquellen Problemstellung

4. Motivation Beispiel Banküberweisung: 1. < T: read( Konto1 ) > 2. < T: update Konto1. Betrag von 0 auf 100 > 3. < T: update Konto2. Betrag von 1000 auf 900 > Kommt es nach Schritt 2 zu einem Ausfall, sind die Daten nicht mehr konsistent. Warum Transaktionen? Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick AbgrenzungMotivation Fehlerquellen Problemstellung

5. Fehler1: Dirty Read 1. <T1 Start> 2. <T1 Update Konto1 10.2000, 2.000> 3. 4. 5. 6. 7. <T1 Update Konto2 1.000, 9.000> 8. <T1 Commit> <T2 Start> <T2 Update Konto 1: * 1,04> <T2 Update Konto 2: * 1,04> <T2 Commit> Zinsen für 8.000 Euro wurden nicht berechnet! Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung MotivationFehlerquellen Problemstellung

6. Fehler 2: Unrepeateable Read 1. <T1 Start> 2. <T1 Read Konto1> 3. <T1 Update Konto 10.000, 2.000> 4. 5. 6. 7. 8. 9. <T1 Update Konto2 1.000, 9.000> 10. <T1 Commit> <T2 Start> <T2 Read Konto 1> <T2 Read Konto 2> <T2 Sum Konto 1, Konto2> <T2 Commit> Gesamtsumme wird falsch berechnet, Werte wurden gelesen, während sie geändert wurden! Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung MotivationFehlerquellen Problemstellung

7. Fehler 3: Lost Update 1. <T1 Start> 2. <T1 temp 1 = Konto1 + 1.000> 3. 4. 5. 6. 7. <T1 Konto 1 = temp 1> 8. <T1 Commit> <T2 Start> <T2 temp 2 = Konto 1 + 2000> <T2 Konto1 = temp 2> <T2 Commit> 2.000 Euro Zubuchung gehen verloren! Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung MotivationFehlerquellen Problemstellung

8. Problemstellung • Die Abbildung von Geschäftsfällen müssen in der Datenbank abgesichert werden gegen: • Physische Fehler • Unkontrollierte unvereinbare gleichzeitige Zugriffe auf den Datenbestand • Inkonsistente Benutzereingaben Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung MotivationFehlerquellen Problemstellung

9. R R‘ M‘ M Was ist Konsistenz? • Physisch: korrekte interne Repräsentation und Speicherung der Daten im Datenbanksystem • Logisch: Übereinstimmung mit dem abzubildenden Realitätsausschnitt R: Realität M: Modell Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Konsistenz Transaktion

10. Was ist eine Transaktion? • Eine Transaktion ist für einen SQL Server eine in sich geschlossene Arbeitseinheit. • Eine Arbeitseinheit wird entweder vollständig ausgeführt oder gar nicht. • Eine nur teilweise Ausführung einer Arbeitseinheit würde zu Inkonsistenzen der Daten führen. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Konsistenz Transaktion

11. Begin Trans Begin Trans Begin Trans Begin Trans Begin Trans Commit Commit Commit Commit Commit Verschachtelte Transaktionen Main Transaction Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Konsistenz Transaktion

12. ACID-Eigenschaften • Atomicity • Consistency • Isolation • Durability Einleitung DefinitionenACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability

13. Begin Trans Begin Trans Commit Rollback ACID: Atomicity • Alles oder Nichts Prinzip • In Fehlersituationen wird die Transaktion abgebrochen und der Datenbestand wird in seinen ursprünglichen Zustand zurückversetzt. Einleitung DefinitionenACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability

14. ACID: Consistency • Konsistenz = Widerspruchsfreiheit • Vor Begin und nach dem Ende einer Transaktion muss ein konsistenter Zustand der Datenbank vorliegen. • Während einer Transaktion können die Daten inkonsistent sein. • Jede technisch implementierte Integritätsbedingung muss erfüllt sein. Einleitung DefinitionenACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability

15. Trans1 Trans2 Trans3 ACID: Isolation • Jede Transaktion soll so durchgeführt werden, als wäre sie die einzige. • Änderungen am Datenbestand durch eine Transaktion dürfen für andere Transaktionen erst am Ende der Transaktion sichtbar sein. • Kein Unterschied zwischen Ein- und Mehrbenutzerbetrieb. Einleitung DefinitionenACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability

16. Trans1 ACID: Durability • Nach Abschluss einer Transaktion müssen alle Änderungen am Datenbestand auf einem sicheren Speichermedium festgehalten sein. Einleitung DefinitionenACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability

17. Nebenläufigkeit: Concurrency • Mehrere Transaktionen laufen gleichzeitig ab (Concurrency: Nebenläufigkeit) • Mehrere Benutzer greifen gleichzeitig auf den Datenbestand zu. • Transaktionen können im Konflikt zueinander stehen. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeit Transaktionssicherung Ausblick Ansätze

18. Ansätze: pessimistisch vs. optimistisch • Optimistischer Ansatz: • Alle Clients können auf alle Informationen zugreifen • + keine Wartezeiten • - Operationen müssen kommutativ sein • - Umverteilung in sehr kleine Operationseinheiten keine Transaktionalität • Pessimistischer Ansatz: • Verwendete Daten sind für andere Clients z.T. gesperrt • + Wahrung der ACID-Eigenschaften • - Einrichtung von Sperrmechanismen notwendig • - evtl. Wartezeiten durch Sperren / Integritätsprüfungen Einleitung DefinitionenACID-EigenschaftenNebenläufigkeit Transaktionssicherung Ausblick Ansätze

19. Transaktionssicherung • Stored Procedures • Trigger • TP Lite Transaktionalität auf Applikationsebene Transaktionalität auf DBMS-Ebene • Rules • Redo- / Undo-Logging • Locks • Validierung Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick

20. TP Lite • Applikationscode ist ins DBMS integriert. • Funktionalität des DBMS ist erweitert. • Keine Transaktionen zwischen heterogenen DBMS. • Verschiedene aufgerufene SPs laufen als unterschiedliche Serverprozesse. • Jeder Aufruf initiiert einen neuen Serverprozess (im Unterschied zu TP Heavy) Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick Applikationsebene: Stored Procedures Trigger TP-Lite

21. Transaktionalität auf Applikationsebene Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick

22. Stored Procedures • Applikationscode, der mit SQL in das DBMS integriert ist. • Alle Anweisungen der Prozedur werden ausgeführt, wenn die Prozedur aufgerufen wird • Hat ACID-Eigenschaften (bei DB2, Oracle) • Leistungsverhalten besser als bei SQL-Anweisungen, die von der Applikation einzeln aufgerufen werden. • wiederverwendbar Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick Applikationsebene: Stored Procedures Trigger TP-Lite

23. Trigger • Applikationscode, der mit SQL in das DBMS integriert ist. • Ein mit einem Ereignis (insert, delete, update) verbundene Aktion, die eine Veränderung im Relationsinhalt nach sich zieht. • (zusammengesetzte) SQL-Anweisung, die automatisch bei einer Änderung einer benannten Tabelle ausgeführt wird. • Wird verwendet um referenzielle Integrität zu erzwingen, komplexe Geschäftsregeln durchzusetzen und Datenveränderungen zu überwachen. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick Applikationsebene: Stored Procedures Trigger TP-Lite

24. Modell Typ Höhe Farbe Blizzard Tourenrad 26 Blau Flash Rennrad 26 Blau Trigger Jockl City-Bike 28 Rot Extreme Tourenrad 20 Weiss Boulder Bonanza 20 Rot Deleted (upd_old) Trans Modell Typ Höhe Farbe Runner Rennrad 26 Schwarz Boulder Bonanza 28 Rot Inserted (upd_new) Modell Typ Höhe Farbe Extreme Tourenrad 20 Weiss Boulder Bonanza 20 Rot Trigger: inserted/deleted delete insert Integritäts-prüfung Kopie der veränderten Daten HAUPTSPEICHER Kopie der eingefügten Daten Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick Integrity Rules Stored Procedures Trigger TP-Lite

25. TP Lite • Applikationscode ist ins DBMS integriert, wird auf dem Server ausgeführt. • Funktionalität des DBMS ist erweitert. • Keine Transaktionen zwischen heterogenen DBMS. • Verschiedene aufgerufene SPs laufen als unterschiedliche Transaktionen. • Jeder Aufruf initiiert einen neuen Serverprozess (im Unterschied zu TP Heavy) • Bsp.: MSSQL: Stored Procedures; Informix: user defined routines) Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick Applikationsebene: Stored Procedures Trigger TP-Lite

26. Transaktionalität auf DBMS-Ebene Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

27. Farbe Blau Grün Gelb Schwarz violett rot <Null> Entity Rule • In einer Grundrelation sind Null-Werte nicht zulässig. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

28. Farbe Modell Typ Höhe Farbe Blau Bizzard Tourenrad 26 Blau Grün Flash Rennrad 26 Blau Gelb Jockl City-Bike 28 Rot Schwarz Extreme Tourenrad 20 Weiss violett rot Boulder Bonanza 20 Weiss weiss Integrity Rules • Ein Eckstein des relationalen Modells, sichergestellt durch referentielle Integrität. • Referentielle Integrität: Jede Wertausprägung eines Foreign Keys muß mit einer Wertausprägung eines Primary Keys in einer verknüpften Tabelle übereinstimmen. FK PK Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

29. Enterprise Rules • Vom Unternehmen festgelegte Bedingungen, die die Regeln der realen Welt in der Datenbank abbilden. Abteilung 5 20 MA max. Tabelle „Mitarbeiter“ darf maximal 20 Personen enthalten, die Abteilung 5 zugeordnet sind. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

30. Logging: Log-Writer Database Buffer Shared Pool Redo Log Buffer SGA LGWR Benutzer-Prozesse DBWR Online Redo Log-Dateien Datendateien Archive Offline Redo Log-Dateien Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

31. Logging einer Transaktion • Schreib-Transaktionen werden in ein Log geschrieben, bevor sie auf der Datenbank ausgeführt werden. • Commits werden ins Log geschrieben, nachdem sie auf der Datenbank durchgeführt wurden. Logbuch: 1. <T1 Start> 2. <T1 Konto 1 700, 600> 3. <T1 Konto 2 200, 300> 4. 5. 6. 7. <T1 Commit> Datenbank: <Konto 1 Update 600> <Konto 2 Update 300> <Commit> Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

32. Arten von Sperren: R/W • Lesesperre (Rlock): hat eine Transaktion eine Lesesperre auf ein Objekt gesetzt, darf keine andere Transaktion darauf schreiben. • Schreibsperre (Xlock): hat eine Transaktion eine Schreibsperre auf ein Objekt gesetzt, darf keine andere Transaktion darauf lesen oder schreiben. Kopatibilitätsmatrix: Gehaltene Sperre: Rlock Xlock Rlock Ja Nein Angeforderte Sperre: Xlock Nein Nein Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

33. Modell Typ Höhe Farbe Blizzard Tourenrad 26 Blau Flash Rennrad 26 Blau Jockl City-Bike 28 Rot Extreme Tourenrad 20 Weiss Modell Typ Höhe Farbe Boulder Bonanza 20 Rot Blizzard Tourenrad 26 Blau Flash Rennrad 26 Blau Jockl City-Bike 28 Rot Extreme Tourenrad 20 Weiss Boulder Bonanza 20 Rot Arten von Sperren: Granularität • Ein modernes DBMS errichtet automatisch Sperren auf der kleinsten möglichen Ebene. Rowlock Tablock DML-Lock: Keine Manipulationsänderungen DDL-Lock: Keine Definitionsänderungen Pagelock Blocksperre Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

34. Arten von Sperren: Isolationsgrade • Read_Uncommited: • Daten können jederzeit gelesen werden. • Read_Committed: • Nur bestätigte Daten können gelesen werden. • Repeatable Read: • Dieselbe Anfragen liefern dasselbe Resultat. • Serializable: • Transaktionen, die gemeinsame Daten benutzen, werden faktisch nacheinander ausgeführt. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

35. Fehler 4: Deadlocks 1. <T1: Start> 2. <T1: writelock (Konto 1)> 3. <T1: read (Konto 1)> 4. <T1:write (Konto 1)> 5. 6. 7. 8. <T1: writelock (Konto 2)> 9. <T2: Start> <T2: writelock (Konto 2)> <T2: read (Konto 2)> <T2: writelock (Konto 1)> T1 wartet auf T2 T2 wartet auf T1 Deadlock! Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

36. Two-Phase-Locking • Jedes Datenelement wird vor dem Zugriff gesperrt und irgendwann nach dem Zugriff wieder freigegeben. • In der 1. Phase werden Sperren nur angefordert, in der zweiten Phase nur freigegeben. • In der 2. Phase darf eine Transaktion keine Sperren mehr anfordern, da sonst ein nicht serialisierbarer Ablauf entstehen könnte. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

37. Two-Phase-Locking: Beispiel <T2: Start> <T2: readlock (Konto 1)> <T2: read (Konto 1)> <T2: readlock (Konto 2)> <T2: read (Konto 2)> <T2: unlock (Konto 1)> <T2: unlock (Konto 2)> <T2: Commit> 1. <T1: Start> 2. <T1: writelock (Konto 1)> 3. <T1: write (Konto 1)> 4. <T1: unlock (Konto 1)> 5. 6. 7. 8. 9. 10. 11. 12. 13. <T1: writelock (Konto 2)> 14. <T1: write (Konto 2)> 15. <T1: unlock (Konto 2)> 16. <T1: Commit> Ende 1. Phase Fehler! Phantom Problem Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

38. Transaktionen: Serialisierbarkeit • Serialisierbarkeit durch Schedules • Serialisierbarkeit ist der parallele Ablauf von Transaktionen in einer Weise, die einem seriellen Ablauf entspricht. • Schedule: serialisierte, performance-optimierte und konsistenzsichernde Verzahnung von Transaktionen Nebenläufige Transaktionen steigern die Performance. Nebenläufige Transaktionen gefährden die Konsistenz. ? Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

39. Serialisierung: Schedule • Serialisierbare Schedules gewährleisten, dass die einzelnen Schritte der verschiedenen Transaktionen serialisierbar sind (also nebeneinander ausgeführt werden können). • Der Scheduler (System-Komponente) prüft die Transaktionen auf Serialisierbarkeit. • Der Scheduler setzt und löscht Sperren automatisch. • Dadurch wird die Serialisierung und Verzahnung der beteiligten Transaktionen gewährleistet. Konfliktserialisierbarkeit Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

40. Serialisierbarkeitsgraph • Ein Pfeil führt von Transaktion Tm zu Transaktion Tn, wenn Tm vor Tn auf dasselbe Datenbankobjekt zugreift und mindestens eine Operation eine Schreiboperation ist. • Enthält der Serialisierbarkeitsgraph keine Zyklen, sind die Transaktionen serialisierbar. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

41. T2 T1 T3 Serialisierbarkeitsgraph: Beispiel T1, T2, T3 bilden den Schedule S - T1 liest A, bevor T2 A schreibt: Pfeil von T1 nach T2 - T2 schreibt A bevor T3 A liest: Pfeil von T2 nach T3 - T3 liest B, bevor T1 B schreibt: Pfeil von T3 nach T1 Der Serialisierbarkeitsgraph ist zyklisch, die Transaktionen sind nicht serialisierbar. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

42. Drei-Phasen Validierung • Alle Transaktionen werden zunächst ohne Rücksicht auf Konflikte durchgeführt und anschließend wird geprüft, welche parallel ablaufen durften und welche nicht. • 1. Phase: Transaktionen dürfen in der Datenbank nur lesen, Schreiboperationen werden ins Logbuch eingetragen. • 2. Phase (Validierungsphase): das DBMS testet, welche Konflikte die Transaktion mit parallelen Transaktionen hat. • 3. Phase: falls die Validierung erfolgreich war, werden die Schreiboperationen aus dem Logbuch in die DB übertragen; falls nicht, wird die Transaktion nach Abschluss der parallelen Transaktionen nochmals durchgeführt. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

43. Mögliche Validierungszustände • 1. Transaktionen wurden beendet, bevor die neue Transaktion begann: keine Validierung notwendig. • 2. Transaktionen, die während der Lesephase der neueren Transaktion ihre Schreibphase beendeten: Validierung der Schreiboperationen der älteren gegen die Leseoperationen der neueren Transaktion. • 3. Transaktionen, die während der Validierungsphase der neueren Transaktion ihre Schreibphase beendete: Validierung der Schreiboperationen der älteren gegen Lese- und Schreiboperationen der neueren Transaktion. T1: R/W T2: R/W ? T1: W T2: R ? T1: W T2: R/W Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung

44. Ausblick: verteilte Systeme Einfache und schnelle Verknüpfung der Anwendungssysteme auf Basis flexibeler Kollaborations-szenarien. Unternehmensübergreifende Interoperabilität auf Basis einer gemeinsam genutzten Plattform. Zukünftige ERP-Lösung Datenverarbeitung nahezu in Echtzeit über alle Applikationen, hinweg. Hohe Datenqualität durch unternehmens-übergreifend integrierte Verwaltung verteilt gehaltener und gepflegter Datenbestände. Quelle: Detecon White Paper: ERP-Strategien im Collaborativen Busniess, März 2003 Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherungAusblick Interaktion Two Phase Commit Three Phase Commit TP Heavy

45. Transaktionen der Zukunft Quelle: Detecon White Paper: ERP-Strategien im Collaborativen Busniess, März 2003 Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherungAusblick Interaktion Two Phase Commit Three Phase Commit TP Heavy

46. Two-Phase-Commit • 1. Phase: Prepare-to-Commit-Anfrage des Koordinators an alle Teilnehmer, die Transaktion vorzubereiten (Can Commit?). Die Teilnehmer führen die Operatonen aus und antworten mit „Ready to Commit!“. • 2. Phase: Der Koordinator sendet je nach Reaktion der Teilnehmer (Ready/Not Ready) sein globales Commit oder Abort. Die Teilnehmer antworten mit „Have Committed“. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherungAusblick Interaktion Two Phase Commit Three Phase Commit TP Heavy

47. Three-Phase Commit • 1. Phase: Prepare-to-Commit-Aufruf des Koordinators an alle Teilnehmer, ihre Operationen auszuführen (Can Commit?). Die Teilnehmer führen die Operationen aus und antworten mit „Ready!“. • 2. Phase: Der Koordinator sendet je nach Reaktion der Teilnehmer (Ready/Not Ready) eine Prepare- oder Abort-Aufforderung. Die Teilnehmer antworten mit „Acknowledged“. Schlägt der Koordinator fehl, führen die Teilnehmer automatisch einen Abort durch. • 3. Phase: Sendet ein Teilnehmer kein „Acknowledged“ gibt der Koordinator einen globalen Abort aus, bestätigen alle Teilnehmer positiv, sendet der Koordinator ein globales Commit. Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherungAusblick Interaktion Two Phase Commit Three Phase Commit TP Heavy

48. Transaktionsmonitoring: TP-Heavy • ACID-Aktualisierungen werden durch mehreren heterogenen Ressourcenmanagern durchgeführt und bleiben trotzdem im Rahmen einer einzigen Transaktion. • Garantierte Neutralität gegenüber Ressourcen. • Multiplexing der Client-Anfragen: TP-Monitor ist „Platzanweiser“ und weist DLL-Ausführungen Serverklassen (Pools von bereits laufenden Prozessen oder Threads) zu (Trichterfunktion). • Bei Bedarf erzeugt der TP-Monitor neue Serverklassen (load balancing) • Priorisierung der Anfragen (RPCs, MOM-Queues, Batch-Läufe etc.) Einleitung DefinitionenACID-EigenschaftenNebenläufigkeitTransaktionssicherungAusblick Interaktion Two Phase Commit Three Phase Commit TP Heavy

49. Vielen Dank für Ihre Aufmerksamkeit! Ende