Online Transaction Processing
Geschwurbel von Daniel Schwamm (25.10.1994)
Splitter-Infos
Proprietäre, grossrechnergestützte Transaktionssysteme (TS) übertreffen derzeit
die C/S-TS bzgl. Sicherheit und Performance bei Weitem. Aber: Mainframe-TS
funktionieren nicht in heterogener Rechnerumwelt.
Online Transaction Processing entstand bereits in den 70ern, v.a. im operationellen
Bereich. Entsprechend lang wurde an den TP-Monitoren herumgefeilt, sodass
CICS nahezu perfekt geworden ist.
Für Transaktionen gilt das ACID-Prinzip: Atomic,
Consistency, Isolated, Durability. Die Sicherung dieser Prinzipien erfolgt
nahezu immer über das 2PC-Protokoll, Rollback- und Recovery-Mechanismen,
Zugriffsblockaden und Checkpoints.
2-Phase-Commit-Protokoll (vorsichtige Commit-Strategie):
-
Phase: Jede Instanz führt Prepare-to-Commit herbei.
Zusage: Alles okay und jederzeit wieder in den Ursprungszustand zu versetzen!
-
Phase: Commit wird durchgeführt. Die Transaktion ist damit
unwiderruflich ausgeführt. Voraussetzung dazu ist, dass
alle Instanzen die 1.Phase erfolgreich ausführten.
TP-Monitore ex. auch bei C/S-Systemen, z.B. Tuxedo. Warum
eigentlich, dort könnte doch der Server dessen Arbeit übernehmen? Im
Prinzip schon, aber bei sehr vielen Anfragen würde der DB-Server sich
ständig duplizieren, bis Speichermangel eintreten würde. Zudem
könnten die ganzen Server, die auf das DBMS zugreifen, nur schwerlich ein
2PC-Protokoll führen. Einfacher ist es daher, den TP-Monitor als zentrale
Verwaltungsinstanz vor dem DBMS anzusetzen und ihn das 2-PC-Protokoll abwickeln
zu lassen.
"remote" versus "distributed": "remote" bedeutet, dass
ein Client die Kontrolle über einen entfernten Zugriff behält. Das
ist mit umständlicher Client-Programmierung verbunden, erhöht die Kommunikation
und fördert Inkonsistenzen. "distributed" bedeutet, dass der Client
den Auftrag als Ganzes an den Server sendet und nur noch auf das Ergebnis zu
warten braucht, während der Server intelligent genug sein muss, um
auch komplexere Anfragen erfüllen zu können.
Interoperabilität: Ist gegeben, wenn zwei inkompatible
Computer sich über ein RN verständigen können => macht
Kommunikationsstandards und Darstellungsstandards nötig. Z.B. von TCP/IP gesagt.
SNA LU 6.2 (ähnlich OSI-TP, das auch OSI-CCR umfasst) erlaubt
Interoperabilität zwischen Mainframes und Workstations.
Portabilität: Ist gegeben, wenn eine SW unabhängig
von der zugrunde liegende HW und der System-SW ist. Z.B. von C gesagt.
Portabilität verlangt APIs.
OSI-TP sieht vor, Transaktionen mittels Dialoge ablaufen zu
lassen, wobei jeder Dialog aus vielen, zurücknehmbaren Transaktionen
bestehen kann. Mittels TP können Transaktionen sogar über
Systemabstürze gerettet werden. Die Dialoge sind verschachtelbar, wodurch
Transaktionsbäume möglich sind (dialog-trees). Sie können peer-to-peer
oder master-slave sein, in jedem Fall kann nur der Initiator des Dialogs
denselben ORDNUNGSGEMÄSS über "commit" beenden. Alle anderen
Teilnehmer können jedoch den Dialog ZURÜCKROLLEN lassen.
X/OPEN plant eine Common Application Environment (CAE),
deren Subkomponente Distributed Transaction Processing (DTP) genauso wie das
OSI-TP asynchrone Request erlauben soll. Die DTP-Protokolle werden bereits von
verteilten TP-Monitoren wie Encina, CICS/6000 und Tuxedo unterstützt.
Obwohl IBM am OSI-RDA mit feilt, arbeitet sie an der eigenen
Distributed Relational Database Architecture (DRDA). Im Gegensatz zu OSI verzichtet
DRDA beim Zugriff auf entfernte DB auf Duplex-Betrieb und
ASN.1-Konvertierung.
Open Data-Base Connectivity (ODBC) von Microsoft erlaubt
unter WINDOWS über SQL-Statements einen einheitlichen, transparenten
Zugriff auf entfernte, verschiedene DBMS. Die ODBC-Funktionalität ist
dabei einfach in einer ".dll"-Datei abgelegt, die von Clients dynamisch
gebunden werden kann.
Borland und Novell mischen auch im Online Transaction Processing-Markt mit:
Sie stellen das Produkt IDAPI (Integrated Database API) vor, dass in direkter
Konkurrenz zu Microsofts ODBC steht. Im Gegensatz zu dem gestattet IDAPI auch
den Zugriff auf nicht-relationale DBMS!