Transaktionsmanagement unter HORIZON

Präsentation zum Thema: "Transaktionsmanagement unter HORIZON"—  Präsentation transkript:

1 Transaktionsmanagement unter HORIZON
Patterns und Mechanismen Oliver Fischer, Technische Architektur; Christian Wicke, Professional Services | JBFOne 2008

2 Ziel dieses Vortrags Sie bekommen einen Überblick über die Grundlagen des Transaktionsmanagements Sie kennen die unterschiedlichen Mechanismen für das Transaktionsmanagement unter HORIZON Sie verstehen wie das Transaktionsmanagement innerhalb einer fachlichen Komponente über Plattformgrenzen (IMS und JDBC) hinweg mit Hilfe des Patterns „Transaktionsklammer mit Gültigkeitsstatus“ funktioniert

3 Agenda Einleitung Grundlagen des Transaktionsmanagements
Patterns und Mechanismen zur Transaktionssicherheit unter HORIZON Einführung in historische Datenhaltung Transaktionsklammer mit Gültigkeitsstatus Verhindern von parallelem Schreiben

4 Agenda Einleitung Grundlagen des Transaktionsmanagements
Patterns und Mechanismen zur Transaktionssicherheit unter HORIZON Einführung in historische Datenhaltung Transaktionsklammer mit Gültigkeitsstatus Verhindern von parallelem Schreiben

5 Warum brauchen wir eine Transaktionsklammer?
Daten, die fachlich zusammen gehören, werden in getrennten technischen Transaktionen geschrieben. Aus fachlicher Sicht ist es erforderlich, dass entweder die Änderung komplett erfolgt, d.h in beiden Systemen, oder dass sie gar nicht erfolgt, also in keinem der Systeme. Beispiel: Bei einem Vertrag wird die Versandart durch eine IMS- Transaktion geändert. Der Preis für den Auszug wird aber durch einen Java-Service per JDBC geändert. Daten die zusammen gehören, werden in getrennten technischen Transaktionen geschrieben. Beispiel: Bei einem Vertrag wird die Versandart durch eine IMS-Transaktion geändert. Der Preis für den Auszug wird aber durch einen Java-Service geändert per JDBC. Aus fachlicher Sicht ist es erforderlich, dass entweder die Änderung komplett erfolgt, d.h in beiden Systemen, oder dass sie gar nicht erfolgt, d.h. in keinem der Systeme.

6 Auswirkungen durch HORIZON auf das Transaktionsmanagement
Serviceorientierte Architekturen wie HORIZON gehen in der Regel von einer losen Kopplung der Geschäftskomponenten aus. Auswirkungen bei loser Kopplung Flexible Reaktion auf Marktanforderungen wird ermöglicht Services unterschiedlicher Anbieter und Produzenten können innerhalb neuer Prozesse kombiniert und angeboten werden Folge ist eine erhöhte Vernetzung zu anderen Produkten, zu anderen Standorten und zu anderen Partnersystemen. Eine Transaktionsklammer innerhalb eines solchen Prozesses über mehrere Fremdsysteme hinweg ist nur schwer oder gar nicht umsetzbar. Im Rahmen von HORIZON 1.1 werden Patterns und Mechanismen für das Transaktionsmanagement zwischen unterschiedlich stark gekoppelten Komponenten erarbeitet.

7 Agenda Einleitung Grundlagen des Transaktionsmanagements
Patterns und Mechanismen zur Transaktionssicherheit unter HORIZON Einführung in historische Datenhaltung Transaktionsklammer mit Gültigkeitsstatus Verhindern von parallelem Schreiben

8 Eigenschaften von SOA-Services
Ausgewählte Eigenschaften, die die Services einer SOA aufweisen müssen: Zustandslos Services merken sich keine Kontext- oder Sessiondaten Konsistent Operationen hinterlassen Geschäftsobjekte in einem konsistenten Zustand Kohäsiv Services werden mit dem Ziel starker Kohäsion¹ und geringer Koppelung zu anderen Services konzipiert Einzeltransaktional „Jeder Aufruf eines Service ist transaktional und genügt somit den ACID-Eigenschaften. Anstatt der Bildung von verteilten oder geschachtelten Transaktionen wird eine lose Kopplung in Verbindung mit compensating actions empfohlen.“ [MWagner06] ¹: In der objektorientierten Programmierung beschreibt Kohäsion, wie gut eine Programmeinheit eine logische Aufgabe oder Einheit abbildet. In einem System mit starker Kohäsion ist jede Programmeinheit (eine Methode, eine Klasse oder ein Modul) verantwortlich für genau eine wohldefinierte Aufgabe oder Einheit.

9 ACID-Prinzip ACID definiert die Anforderungen an eine kurz laufende Transaktion und ermöglicht die Konsistenzerhaltung bei parallel laufenden Transaktionen. Eine Transaktion umfasst eine „Unit of Work“ die entweder komplett ausgeführt wird oder nicht (Commit / Rollback). Atomicity - Eine Transaktion wird entweder ganz oder gar nicht ausgeführt. Transaktionen sind also „unteilbar“. Wenn eine atomare Transaktion abgebrochen wird, ist das System unverändert. Consistency - Nach Ausführung der Transaktion muss der Datenbestand in einer konsistenten Form sein. Isolation - Alle Aktionen innerhalb einer Transaktion werden vor parallel ablaufenden Transaktionen verborgen. Durability- Alle Änderungen einer erfolgreich durchgeführten Transaktion sind dauerhaft. Änderungen überleben auch Systemfehler.

10 ACID und 2-Phase-Commit
Um die ACID - Eigenschaften in eng gekoppelten und verteilten Umgebungen erfüllen zu können, nutzen traditionelle Transaktionsmonitore (beispielsweise IBM IMS, CICS …) und Java EE Application Server das Two Phase Commit Protokoll (2PC) (geschlossen geschachtelte Transaktion). Mehrere separate transaktionssichere Ressourcen können an einer globalen 2PC Transaktion teilnehmen. Eine globale Transaktion umfasst mehrere Aktionen, die für sich transaktionssicher sind, sodass mehrere ACID-Transaktionen konzertiert als Komponenten einer globalen Operation ausgeführt werden, die ebenfalls ACID- Eigenschaften hat. Das 2PC-Protokoll funktioniert nach dem Koordinator- und Teilnehmer-Prinzip, das heißt, in die Transaktion sind immer ein Koordinator und beliebig viele Teilnehmer involviert. Ready for Commit Ressource A Koordinator Aktion Prepare Ressource B Commit

11 Probleme mit 2PC Der Einsatz des 2PC Protokolls ist nur sinnvoll in eng gekoppelten und synchron kommunizierenden Umgebungen, da für den Zeitraum der Transaktion die benötigten Ressourcen exklusiv gesperrt werden. Eine enge synchrone Kommunikation über Komponentengrenzen hinweg widerspricht den Grundgedanken der losen Kopplung in SOA Umgebungen. Bei asynchroner Kommunikation und lang laufenden Business Aktivitäten ist das Sperren von Ressourcen nicht empfehlenswert. Service-Domänen oder Komponenten bündeln funktionale Komponenten mit großer fachlicher Ähnlichkeit (Kohärenz) untereinander und mit möglichst geringer Abhängigkeit von anderen Service-Domänen oder Komponenten. Bei einem sauberen Domänen- und Komponentenschnitt, sollte es keine Notwendigkeit für ACID/2PC-Transaktionen geben. Eigenschaften: minimale Kohäsion, lose Koppelung, Kompensation Domäne 1 Domäne 2 Eigenschaften maximale Kohäsion enge Koppelung ACID Messages

12 Unterschiedliche Kopplungsstufen bedingen unterschiedliche Transaktionsmechanismen
Merkmal für Kopplungsstufe Enge Kopplung Lose Kopplung Kommunikationsart Synchron, z.B. über XBF- Services Asynchron, z.B. über Messages Datenhaltung Gemeinsam, d.h. es wird das gleiche DB-System verwendet Getrennt, z.B. DB2 und Oracle Transaktionssicherheit Über JBF-Transaktionsmanager oder über Transaktionsklammer mit Gültigkeitsstatus Über Kompensation oder garantierte Nachrichtenübertragung Vetrauensstellung Hoch, Daten werden i.d.R. untereinander nicht validiert Niedrig, Daten werden gegenseitig validiert Abhängigkeiten Viele enge Wenige explizite Beispiel Schichten einer Komponente Bündelübergreifende Kopplung, Anbindung von Fremdsystemen

13 Agenda Einleitung Grundlagen des Transaktionsmanagements
Patterns und Mechanismen zur Transaktionssicherheit unter HORIZON Einführung in historische Datenhaltung Transaktionsklammer mit Gültigkeitsstatus Verhindern von parallelem Schreiben

14 Patterns für lose gekoppelte Geschäftskomponenten: Fire and Forget
Fire and Forget: transaktionales Erzeugen einer Nachricht Lose gekoppelte Komponenten werden über einen garantierten, asynchronen Weg, zum Beispiel über Messages, angesprochen. Alle am Prozess beteiligten Komponenten gehen davon aus, dass der Geschäftsvorfall in der Regel erfolgreich abgeschlossen werden kann (Happy Day Szenario). Antworten/Rückmeldungen des gerufenen Services gehen ebenfalls asynchron ein. Beispiel: eine Komponente verbucht eine Zahlung und veranlasst transaktional das Protokollieren der Buchung. Die Protokollierungskomponente verarbeitet die Nachricht und schreibt den Protokollsatz ebenfalls transaktional. Transaktion 1 Transaktion 2 Transaktion 3 Konto Protokollierung AQ Protokoll Buchung DB MQ DB

15 Patterns für lose gekoppelte Geschäftskomponenten: Kompensation
Kompensation ist nicht zwingend das vollständige Zurücknehmen aller Prozessschritte, sondern das Wiederherstellen von konsistenten Systemzuständen. Services einer Geschäftskomponente lassen sich bezüglich ihrer Kompensierbarkeit unterschiedlich klassifizieren: Kompensierbar: die Aktivität lässt sich vollständig durch inverse Aktivitäten kompensieren. Beispiel Stornobuchung: eine Buchung kann durch eine Gegenbuchung kompensiert werden. Nicht kompensierbar: die Aktivität kann nicht kompensiert werden. Beispiel: -Versand Nicht notwendig: die Aktivität muss nicht kompensiert werden. Bei Datenbank-Transaktionen muss beachtet werden, dass die Ergebnisse der zurückzunehmenden Transaktion bereits für andere Transaktionen sichtbar waren und eventuell bereits verwendet wurden. Eventuell erfordert eine Rücknahme der Transaktion Stornierungsgebühren, zum Beispiel die Kompensation einer Sitzplatzreservierung bei Stornierung einer Bahnfahrkarte.

16 Kompensation – das ist zu beachten
! Kompensation – das ist zu beachten Kompensation muss bereits beim fachlichen Design berücksichtigt werden, zum Beispiel durch das Einführen von fachlichen Statuszuständen („angelegt“, „freigegeben“, „storniert“, etc.). Ob ein Service rückgängig gemacht werden kann, ist immer im Prozesskontext zu betrachten. Ein Service muss fachlich so geschnitten sein, dass er sinnvoll in einer technischen Transaktion abzuarbeiten ist. Er darf nicht zu komplex sein, damit eine compensating action einfach zu formulieren ist. Spezielle Kompensationsservices sind in der Regel nicht erforderlich. So reicht zum Beispiel für einen Service createGeschäftsobjekt ein deleteGeschäftsobjekt. Weitere Tipps, Empfehlungen und Best Practices werden derzeit im Projekt HORIZON 1.1 erarbeitet.

17 Patterns für eng gekoppelte Geschäftskomponenten oder innerhalb einer Komponente: JBF-TXManager
Bei enger Koppelung oder innerhalb einer Geschäftskomponente besteht die Möglichkeit, eine Datenbank-Transaktion über mehrere kaskadierte Services zu spannen. Die Verwaltung der Transaktion erfolgt über die Klasse JBFDBTXManager, wobei der Start und die Beendigung der globalen Transaktion in der Anwendung (zum Beispiel im Service) erfolgen muss. Eine Geschäftskomponente kann auf diesem Weg mehrere SQLs (über DAM oder DBObject) absetzen und verschiedene Tabellen verändern. Im Fehlerfall können über einen Rollback sämtliche Änderungen innerhalb der Transaktion rückgängig gemacht werden. Im Erfolgsfall werden über einen Commit sämtliche Änderungen gültig, das ACID-Prinzip wird eingehalten. Geschäftskomponente … JBFDBTXManager.begin(this); /* Starten der Transaktion */ Connection c = JBFDBTXManager.getTXConnectionForCustomer(“4711”); /* Holen der DB-Verbindung */ Jdbc-Anweisungen mit dieser Connection JBFDBTXManager.end(true, this); /* Beenden der Transaktion (mit commit) */ TXManager DB Connectionpool commit

18 Agenda Einleitung Grundlagen des Transaktionsmanagements
Patterns und Mechanismen zur Transaktionssicherheit unter HORIZON Einführung in historische Datenhaltung Transaktionsklammer mit Gültigkeitsstatus Verhindern von parallelem Schreiben

19 Einführung in historische Datenhaltung
Bei der historischen Datenhaltung werden Sätze immer nur in die DB eingefügt (INSERT). Sie werden niemals geändert (UPDATE) oder gelöscht (DELETE). Damit man weiß, welcher Satz gültig ist, wird jeder Satz durch einen Gültigkeitszeitraum qualifiziert. Es gibt verschiedene Varianten für den Gültigkeitszeitraum. In diesen Folien gehen wir vom impliziten „Gültig bis“ aus. Das heißt, ein Satz ist gültig bis zur Gültig-ab-Zeit des nächsten Satzes dieser Entität. Tabelle Zins Tabelle Preis Konto nr Gültig ab Zins Lösch- Status 18 :12 3% aktiv :11 4% Konto nr Gültig ab Preis Lösch- Status 18 :12 5 € aktiv :04 6 € :00 gelöscht

20 Gültig-ab-Zeit wird durch Revision ersetzt
Statt der Gültig-ab-Zeit (Zeitstempel) wird jedem Satz eine Revision zugeordnet. Diese verweist auf eine Revisionstabelle, in der die Gültig-ab-Zeit zu dieser Revision geführt wird: Die Revisionstabelle wird pro Haupt-Entität (Z.B. Produkt, Vertrag, Kunde) geführt und hochgezählt. Tabelle Zins Tabelle Preis Tab. Vertragsrevision Knr Rev Zins Lösch- Status 18 1 3% aktiv 3 4% Knr Rev Preis Lösch- Status 18 1 5 € aktiv 2 6 € 4 gelöscht Knr Rev Gültig ab 18 1 :12 2 :04 3 :11 4 :00

21 Agenda Einleitung Grundlagen des Transaktionsmanagements
Patterns und Mechanismen zur Transaktionssicherheit unter HORIZON Einführung in historische Datenhaltung Transaktionsklammer mit Gültigkeitsstatus Verhindern von parallelem Schreiben

22 Gültigkeitsstatus In der Revisionstabelle wird für jeder Revision ein Gültigkeitsstatus geführt. Der Status kann 3 Zustände annehmen: schwebend, gültig, ungültig Sätze sind dann gültig, wenn deren Revision im Zustand gültig sind. Nicht gültige Sätze werden überlesen. (Im Beispiel wäre dies Revision 4.) Anmerkung: In den folgenden Folien werden der Löschstatus und die Gültig-ab-Zeit nicht mehr dargestellt, da sie für die Lösung egal sind. Tabelle Zins Tabelle Preis Tabelle Vertragsrevision Knr Rev Zins Lös. Sta. 18 1 3% akt. 3 4% Knr Rev Preis Lös. Sta. 18 1 5 € akt. 2 6 € 4 gel. Knr Rev Gültig ab Gültigkeits- status 18 1 ... gültig 2 3 4 schwebend

23 Atomares Schreiben Bei systemübergreifenden (Java + IMS) Schreibzugriffen werden zuerst die Sätze in den DB2-Tabellen geschrieben. Zum Schluss wird die IMS-DB geschrieben und der Gültigkeitsstatus auf gültig gesetzt. Der Ablauf ist wie folgt: Java-Service ermittelt sich neue Revision. Zustand ist vorerst schwebend. Java-Service schreibt fachliche Tabellen mit dieser Revision. Java-Service ruft Host-Tx auf (Revision wird als zusätzlicher Parameter mitgegeben). Host-Tx ändert im IMS und ändert Gültigkeitsstatus auf gültig in einer IMS-Transaktion (atomar) Konto im IMS Tabelle Preis Tab. Vertragsrevision Knr Versandart Turnus 18 eBanking Knr Rev Preis 18 1 5 € 2 6 € Knr Rev Gültigkeits- status 18 1 gültig 2 3 post monatlich 18 4 7 € 18 4 schwebend gültig

24 Agenda Einleitung Grundlagen des Transaktionsmanagements
Patterns und Mechanismen zur Transaktionssicherheit unter HORIZON Einführung in historische Datenhaltung Transaktionsklammer mit Gültigkeitsstatus Verhindern von parallelem Schreiben

25 Verhindern von parallelem Schreiben einer Entität: Problemstellung
Schreiben zwei Prozesse (A und B) gleichzeitig auf gemeinsame Daten, können folgende Probleme auftreten: Die Änderung des Prozesses A wird von B überschrieben. Prozess A erfährt dies jedoch gar nicht. Das heißt, der Datenverlust wird nicht bemerkt. Es kann auch passieren, dass Teiländerungen von beiden Prozessen erfolgen. Das Resultat ist ein Datenmischmasch, den keiner der Prozesse haben wollte. Parallele Schreibzugriffe auf dieselben Daten müssen verhindert werden. Techniken um dies zu verhindern sind bei klassischer (nicht historischer) Datenhaltung: Optimistic Locking (OR-Mapper wie DAM nutzen dies) Sperren des Root-Segments (bei IMS-Datenbanken) Für historische Datenhaltung mit 2 schreibenden Systemen (Java + Host) funktionieren leider beide nicht.

26 Verhindern von parallelem Schreiben einer Entität: Beispiel für Lösung
Zwei Prozesse P1 und P2 (z.B. aci-Batch und Dialog) haben beide den Vertrag mit Revision 30 gelesen und wollen ihn schreiben: P1 ermittelt sich Revision 31 P2 ermittelt sich Revision 32 P1 schreibt Preis, P2 schreibt Zins P2 ist schneller und sperrt Revision 30 per SELECT FOR UPDATE P1 versucht zu sperren, muss wegen Lock von P2 warten P2 prüft auf neuere Sätze. Revision 31 ist nicht gültig, daher ok. P2 macht Revision 32 gültig (Commit, dadurch Freigabe des Locks) P1 sperrt nun Revision 30 P1 prüft auf neuere Sätze. Rev. 32 ist gültig, daher nicht ok. P1 macht Rev. 31 ungültig und gibt Fehlermeldung zurück Tab. Vertragsrevision Knr Rev Gültigkeits- status 18 5 gültig ... 9 30 Tabelle Zins Tabelle Preis Knr Rev Zins 18 5 3% 30 4% Knr Rev Preis 18 9 5 € 18 31 7 € 18 32 5% 18 31 schwebend ungültig 18 32 schwebend gültig

27 Zusammenfassung Je nach Kopplungsstufe gibt es unterschiedlichen Mechanismen für die Transaktionssicherheit. In HORIZON 1.1 werden die Kopplungsstufen der Komponenten und die daraus resultierenden Transaktionsmechanismen verfeinert. Die Transaktionsklammer mit Gültigkeitsstatus ermöglicht eine Transaktionssicherheit über Systemgrenzen hinweg und verhindert paralleles Schreiben.

28 Literaturverzeichnis
[MWagner06] Michael J.M. Wagner, Orchestrierung in der Praxis, DFN-Arbeitstagung 2006 [THorn08] Torsten Horn, Service Oriented Architecture, horn.de/techdocs/soa.htm [aSAPer08] Klaus Huthmacher, agree® Standardarchitektur – Persistenz, Entwicklungsrichtlinien der FIDUCIA IT AG

29 Fragen? – Diskussion? Oliver Fischer Christian Wicke
Anwendungsentwicklung Technische Architektur Christian Wicke Anwendungsentwicklung Projekt Konditionsbaustein

30 Ihr IT-Partner Vielen Dank