Einer für alle – alle für einen!

1. Einer für alle – alle für einen! E3 Verteilte Transaktionen mit .NET-Komponenten Marcel Gnoth – www.gnoth.net

2. Wer bin ich...? • Dipl. Inf. Marcel Gnoth • Entwickler, Trainer, MCSD, Autor • Geschäftsanwendungen, COM, Datenbanken, Verteilte Informationssysteme • www.gnoth.net • aktuelle Folien und Beispiele auf der Webseite • NTeam GmbH, Berlin • www.nteam.de (MS Server Familie, BI, Entwicklung) • Microsoft Gold Certified Partner Marcel Gnoth – www.gnoth.net

3. Inhalt • Die Herausforderung • Einführung Transaktionen • Transaktionen mit dem SQL Server • Mehrbenutzer-Zugriff auf eine Datenbank • Verteilte Transaktionen mit SQL Server • Transaktionen mit ADO.Net • Transaktionen mit COM+ • Steuerung einer COM+ Transaktion Marcel Gnoth – www.gnoth.net

4. Inhalt • Eine transaktionale System.EnterpriseServices – Komponente • Der Distributed Transaction Coordinator (DTC) • Komponente mit verteilten Transaktionen • DTC und andere Welten • Schlußbemerkungen • Links Marcel Gnoth – www.gnoth.net

5. Die Herausforderung Es war einmal ..... Marcel Gnoth – www.gnoth.net

6. Überall Transaktionen • Unser Leben besteht aus Transaktionen • Das alte Beispiel mit den zwei Bankkonten • Eheschließung • Beim Notar Transaktion Server Sparkasse Server Hypobank Konten Konten Konto A + 10 Konto C – 10 Konto B Konto D Marcel Gnoth – www.gnoth.net

7. Die Computerwelt • Verarbeitung von Geschäftsprozessen • SQL-Server / Oracle / MSMQ (Message Queue) • Main Frame Systeme • Zusammenarbeit mit anderen IT-Systemen • Dienste unter Windows • Alle unter einen Hut bringen • TX = Transaktion SQL Server MSMQ Oracle Marcel Gnoth – www.gnoth.net

8. Einführung Transaktionen Marcel Gnoth – www.gnoth.net

9. Merksatz • Eine Transaktion ist eine Menge von Aktionen, die ein System von einem konsistenten Zustand zu einem anderen konsistenten Zustand transformieren. • Ein konsistenter Zustand wird durch die Anwendungslogik definiert. Marcel Gnoth – www.gnoth.net

10. ACID I • Atomicity (Unteilbarkeit) • Alles oder nichts • wenn eine Aktion fehlschlägt, dann Rollback für alle • Consistency (Konsistenz) • System von einem konsistenten zu einem anderen konsistenten Zustand transformieren • abhängig von den Geschäftsregeln • Beispiel: Einfügen in verkettete Liste • Vorgänger und Nachfolger Pointer aktualisieren oder keinen Marcel Gnoth – www.gnoth.net

11. ACID II • Isolation (Isolation) • mehrere Transaktionen gleichzeitig • jede Transaktion läuft für sich allein, als wenn sie die einzige wäre • laufende Transaktionen sind für andere nicht sichtbar • Serialisierbarkeit • Beispiel: Durchsuchen der verketteten Liste • entweder vor dem Einfügen eines Elementes oder danach Marcel Gnoth – www.gnoth.net

12. ACID II – Isolation Beispiel • Transaktion A multipliziert Daten mit Faktor 2 • Transaktion B addiert zu den Daten 1 • zwei Werte: 0 und 10 • Ergebnisse: • A zuerst: 1 und 21 -> (0*2)+1 und (10*2)+1 • B zuerst: 2 und 22 -> (0+1)*2 und (10+1)*2 • Beides gut, aber 1 und 22 oder 2 und 21 sind schlecht! Marcel Gnoth – www.gnoth.net

13. ACID III • Durability (Beständigkeit) • Resultate einer bestätigten Transaktion sind dauerhaft • Computer / Netzwerkausfälle Marcel Gnoth – www.gnoth.net

14. Transaktionen mit SQL-Server Marcel Gnoth – www.gnoth.net

15. Transaktionsverwaltung SQL-Server • Transaktionstypen • Explicit, Autocommit, Implicit • Sperrvorrichtungen • Isolation der Transaktionen • Protokollfunktionen • Rollback bei Systemfehlern Marcel Gnoth – www.gnoth.net

16. Transaktionensmodi • Autocommit • Standardmodus • jede TSQL-Anweisung ist eine einzelne Transaktion • Explicit • BEGIN TRANSACTION, COMMIT, ROLLBACK • Implicit • SET IMPLICIT_TRANSACTIONS ON • Transaktionen starten automatisch, bis COMMIT oder ROLLBACK Marcel Gnoth – www.gnoth.net

17. Beispiel Eine Transaktion mit TSQL und dem iSQLw TSQL Tx.sql Marcel Gnoth – www.gnoth.net

18. Mehrbenutzer – Zugriff Probleme mit der Parallelität Marcel Gnoth – www.gnoth.net

19. Probleme der Parallelität • Viele Anwender aber parallel auf einer Datenbank • zusammenhängende Aktionen eines Anwenders werden in Transaktionen zusammengefaßt • Lesen, Schreiben, Löschen, Einfügen • arbeiten mehrere Anwender gleichzeitig auf der Datenbank, so müssen deren Transaktionen voneinander isoliert werden. • Kompromiss zwischen Isolation und Durchsatz Marcel Gnoth – www.gnoth.net

20. Lost Update • Verlorene Aktualisierungen (Lost Update) • zwei Anwender lesen die gleichen Daten • beide ändern, der letzte gewinnt, die Änderungen des ersten werden überschrieben Begin Transaktion 1 read (Kontostand) Kontostand = Kontostand + 100 write (Kontostand) Commit Transaktion 1 Begin Transaktion 2 read (Kontostand) Kontostand = Kontostand – 20 write (Kontostand) Commit Transaktion 2 Marcel Gnoth – www.gnoth.net

21. Dirty Read • Lesen unbestätigter Daten (Dirty Read) • TX A liest Daten, die TX B geändert, aber nicht bestätigt hat • wenn TX B ein Rollback durchführt ...... Begin Transaktion 1 Kontostand = 5000 write (Kontostand) Rollback Transaction 1 Begin Transaktion 2 read (Kontostand) Kontostand = Kontostand – 20 write (Kontostand) Commit Transaciton 2 Marcel Gnoth – www.gnoth.net

22. Nonrepeatable Reads • Nicht wiederholbarer Lesevorgang (Nonrepeatable Reads) • eine Transaktion liest eine Zeile zweimal und erhält unterschiedliche Daten • Zeile wurde von anderer TX aktualisiert oder gelöscht • mindestens zwei Lesevorgänge • Fremd TX hat COMMIT durchgeführt Marcel Gnoth – www.gnoth.net

23. Nonrepeatable Reads Begin Transaktion 1 read (Kontostand) read (Kontostand) ...... Begin Transaktion 2 read (Kontostand) Kontostand = Kontostand – 20 write (Kontostand) Commit Transaktion 2 Marcel Gnoth – www.gnoth.net

24. Phantoms • Lesen eines Phantoms (Phantoms) • TX A erhält Datensätze, die einem Kriterium entsprechen (WHERE-Klausel) • TX B ändert einen Datensatz oder fügt einen hinzu • TX A erhält beim erneuten Abfragen eine andere Menge von Datensätzen Marcel Gnoth – www.gnoth.net

25. Phantoms Begin Transaktion 1 Select * From Konto Where Kontostand > 100 Select * From Konto Where Kontostand > 100 ...... Begin Transaktion 2 read (Kontostand) Kontostand = 80 write (Kontostand) Commit Transaktion 2 Marcel Gnoth – www.gnoth.net

26. Sperren • Isolation-Eigenschaft einer Transaktion • Viele Anwender arbeiten gleichzeitig auf einer Datenbank -> „Problem der Parallelität“ • SET TRANSACTION ISOLATION LEVEL • Kompromiß zwischen Isolierung und Performanz • hohe Isolation -> Anwender blockieren sich gegenseitig, System wird langsam • geringe Isolation -> Anwender können inkonsistente Daten erhalten Marcel Gnoth – www.gnoth.net

27. Isolationsstufe Dirty Read Nicht wiederholbarer Lesevorgang Phantom Read Uncommitted Ja Ja Ja Read Committed Nein Ja Ja Repeatable Read Nein Nein Ja Serializable Nein Nein Nein Isolationsstufen Marcel Gnoth – www.gnoth.net

28. Verteilte Transaktionen mit SQL-Server Marcel Gnoth – www.gnoth.net

29. Transaktionen zwischen mehreren Servern • SQL-Server ist ein Ressourcenmanager • verwaltet seine Daten über Transaktionen • Transaktionen zwischen verschiedenen Ressourcenmanagern müssen koordiniert werden • Distributed Transaction Coordinator (DTC) • SQL-Server kann mit Transaktions-Managern zusammenarbeiten • X/Open XA-Spezifikation unterstützen Marcel Gnoth – www.gnoth.net

30. Transaktionen mit TSQL • Linked Server • BEGIN DISTRIBUTED TRANSACTION • BEGIN TRANSACTION • OLE DB-Datenquelle ITransactionJoin-Schnittstelle • TX wird von lokal zur verteilten TX heraufgestuft EXEC sp_addlinkedserver @server='TXTest', provider='SQLOLEDB', @datasrc='SPOCK' EXEC sp_addlinkedsrvlogin 'TXTest', 'false', NULL, 'sa', '' Marcel Gnoth – www.gnoth.net

31. XACT_ABORT • automatisches Rollback bei Laufzeitfehler • SET XACT_ABORT ON • tritt in einer TX ein Laufzeitfehler auf, wird Rollback für die gesamte TX durchgeführt • SET XACT_ABORT OFF • nur die Anweisung, die den Laufzeitfehler auslöst wird zurückgesetzt, die Tx läuft weiter • werden keine verschachtelten Tx unterstützt dann SET XACT_ABORT ON setzen Marcel Gnoth – www.gnoth.net

32. Code Set XACT_ABORT On BEGIN DISTRIBUTED TRANSACTION INSERT INTO [pubs].[dbo].[authors] ([au_id], [au_lname], [au_fname], [phone]) VALUES ('111-22-3333', 'Duck', 'Donald', '123456') INSERT INTO [TXTest].[pubs].[dbo].[authors] ([au_id], [au_lname], [au_fname], [phone]) VALUES ('111-22-3333', 'Duck', 'Donald', '123456') COMMIT Marcel Gnoth – www.gnoth.net

33. DEMO Verteilte Transaktion mit iSQLw und TSQL Marcel Gnoth – www.gnoth.net

34. Transaktionen mit ADO.Net Marcel Gnoth – www.gnoth.net

35. Transaktionen mit ADO.Net • SQLConnection, OLEDBConnection • BeginTransaction • SQLTransaction, OLEDBTransaction • Commit, Rollback cnScotty = new SqlConnection("data source = .....); cmdScotty = new SqlCommand(query,cnScotty); cnScotty.Open(); Txn = cnScotty.BeginTransaction(ReadCommitted); cmdScotty.Transaction = Txn; cmdScotty.ExecuteNonQuery(); Marcel Gnoth – www.gnoth.net

36. Transaktionen mit ADO.NET • Tx – Anweisungen bedeuten Roundtrip zum Server (Begin, Commit, Rollback) • keine eigene Unterstützung von verteilten Transaktionen, andere Mechanismen benutzen • TSQL-Anweisungen, die sich auf Linked Server beziehen • COM+ und DTC (folgt....) Client Server Accounts Local Transaction ADO.NET Account A Account B OLE DB SQL TDS Marcel Gnoth – www.gnoth.net

37. Client ADO OLE DB DB DB OLEDB und ODBC – APIs • direkte Programmierung ohne ADO • ermöglichen ebenfalls Steuerung von verteilten Transaktionen • aufwendige Programmierung • nur in Sonderfällen sinnvoll Marcel Gnoth – www.gnoth.net

38. COM+ Überblick Theorie (nur ein wenig  ) Marcel Gnoth – www.gnoth.net

39. Überblick COM+ • Transaktionen • Ressourcen Management • Just in Time Aktivierung (JIT), Objekt-pooling • Synchronisation bei parallelem Zugriff auf Komponenten (Threads) • Deklarative Sicherheit • Loosely coupled events, Queued Components • Compensating Resource Managers (CRM) • ermöglicht nicht transaktionalen Ressourcen an Transaktionen teilzuhaben (Filesystem,...) Marcel Gnoth – www.gnoth.net

40. COM+ Welt und .Net • die üblichen Verdächtigen..... .NET Enterprise Services Common Language Runtime COM+ Services COM and Win32 Marcel Gnoth – www.gnoth.net

41. Applikationstypen • Bibliotheksanwendung (ActivationOption.Library) • Komponente im Prozeßraum des Clients • bessere Performance, nicht alle COM+ Dienste verfügbar • Serveranwendung (ActivationOption.Server) • Komponente in eigenem Mutterprozeß • stabiler, da eigener Prozeß, mehr Möglichkeiten • Dienst Client Process Dllhost.exe Process Library Application Server Application Class A Class B Marcel Gnoth – www.gnoth.net

42. Transaktionen in COM+ .Net Enterprise Services Marcel Gnoth – www.gnoth.net

43. Attribute einer COM+ Komponente • Transaction • Disabled • Tx-Attribut wird von COM+ ignoriert • Not Supported • Komponente wird in einem Kontext ohne Tx aktiviert • Supported • beteiligt sich an Tx, wenn vorhanden [Transaction(TransactionOption.Required)] Class MyTxClass : ServicedComponent {…} Marcel Gnoth – www.gnoth.net

44. Attribute einer COM+ Komponente • Required • Komponente muß in einem transaktionalen Kontext laufen • Requires New • Für die Komponente wird ein neuer transaktionaler Kontext angelegt. Marcel Gnoth – www.gnoth.net

45. Transaktions – Ströme • Gruppe von COM+ Komponenten in der selben Tx -> Tx-Stream • Zugriff auf Transaktion ID (unit-of-work ID) und Transaktion Objekt über Objekt Kontext • Database Connections nehmen automatisch teil Transaction Stream Root = Required oder Requires New Sub1 Root Client Root Sub1 und Sub2 = Required oder Supported Sub2 Marcel Gnoth – www.gnoth.net

46. Done Consistent Done Consistent Done Consistent Das Ergebnis einer Transaktion • Ergebnis der Transaktion und Lebensdauer der Komponente • Pro Objektkontext: Consistent- und Done Flag • Pro Transaktion: Abort Flag Transaction Stream Sub1 Root Client Root Sub2 Abort Marcel Gnoth – www.gnoth.net

47. Done und Consistent - Flags • Done • False wenn Objekt in Kontext Aktiviert wird • Wenn am Ende des Methodenaufrufs Flag = True, dann wird Objekt deaktiviert -> Objekt wird nicht mehr benötigt • Consistent (Happy-Flag) • wenn alle Komponenten Consistent-Flag = True, dann kann Commit für die Tx durchgeführt werden Marcel Gnoth – www.gnoth.net

48. Abort Flag • Abort (Doomed-Flag) • gilt für die gesamte Tx • initialisiert mit False • wenn True, dann muß Abort für die Tx durchgeführt werden • wenn True, dann kann es nicht mehr auf False zurückgesetzt werden Marcel Gnoth – www.gnoth.net

49. Ergebnis der Transaktion • wenn Aufruf des Root-Client zum Root-Objekt zurückkehrt entscheidet COM+ über Ergebnis • Wenn Abort-Flag = True -> Abort • Wenn eines der Consistent-Flags = False -> Abort • Wenn Abort=False, alle Consistent=True -> Commit • Wenn Done-Flag = True -> Objekt deaktiviert • Ist Done-Flag = False -> weitere Aufrufe in der gleichen Tx möglich. Nicht empfohlen! Marcel Gnoth – www.gnoth.net

50. Ergebnisse • Consistent – Flag entscheidet über Commit einer Transaktion • Done – Flag entscheidet, ob Objekt deaktiviert werden kann • Objekt kommt in Pool, Object – State geht verloren • Ressourcen werden freigegeben • Client behält eine Objektreferenz • bei erneuten Aufrufen erhält Client ein Objekt aus Pool oder ein neues Marcel Gnoth – www.gnoth.net