\chapter{Tycoon als transaktionale Umgebung}
\label{umgebung-kap}

Zur Unterst"utzung langlebiger Aktivit"aten mu"s das Tycoon-System
(\cite{Matt93}) mit einem
daf"ur angemessenem Transaktionsmodell ausgestattet werden. Langlebige
Aktivit"aten sollten aus Gr"unden der Ablaufkontrolle durch strukturierte
Transaktionen implementiert werden, weswegen die in Tycoon vorzufindenden
flachen Transaktionen ungeeignet sind. 
Als Kompromi"s zwischen Ausdrucksm"achtigkeit und Realisierbarkeit,
besonders im Hinblick auf die Einbindbarkeit externer Dienste, ist eine
Strukturierung flacher Transaktionen durch persistente Sicherungspunkte zu
sehen. Eine langlebige (Trans-) Aktion wird dabei in sequentielle
Teilabschnitte partitioniert, die durch die Sicherungspunkte begrenzt werden.
Die Persistenz der Sicherungspunkte garantiert nach einem Ausfall, da"s der
letzte durch einen Sicherungspunkt markierte Zustand wiederhergestellt werden
kann. Da transaktionale externe Dienste wie z.B. Datenbanksysteme nur flache
Transaktionen unterst"utzen, m"ussen diese durch einen zweistufigen Ansatz in
Tycoon integriert werden, der zum Beispiel an ConTracts~\cite{WaRe91} oder
Sagas (\cite{GMS87}) erinnert.

Als Grundlage f"ur die Diskussion er"ortert der n"achste
Abschnitt die Bedeutung
des Transaktionskonzeptes im Kontext einer persistenten Programmiersprache. Die
"ubliche Definition einer Transaktion l"auft
auf die ACID-Eigenschaften hinaus,
die aber f"ur Datenbanksysteme gepr"agt wurden. Inwieweit diese Eigenschaften
noch f"ur persistente Programmiersprachen anwendbar sind und welche Aussagen
sie in diesem Zusammenhang machen, wird im folgenden Teilabschnitt gekl"art.
Die daran anschlie"sende Begr"undung der Wahl des Transaktionsmodells
geht insbesondere auf die Bed"urfnisse langlebiger Aktivit"aten ein.
Nach einer kurzen
Darstellung der in Tycoon realisierten Transaktionsschnittstelle f"ur
persistente Sicherungspunkte wird das Kapitel mit einer Klassifikation der in
offenen persistenten Programmiersprachen vorkommenden Ressourcen abgeschlossen.
Die Klassifikation reflektiert die f"ur die transaktionalen Algorithmen
relevanten Charakteristika der Ressourcen und begr"undet die Gliederung der
Kapitel~3--5.

\section{Bedeutung des Transaktionskonzeptes f"ur persistente
Programmiersprachen}
\label{ta-eigenschaften-sec}

Das Transaktionskonzept entstammt urspr"unglich dem Datenbankbereich
(\cite{EGLT76}), wo
es als Konstrukt eingef"uhrt wurde, um dem Programmierer ein
einfache Semantik seiner Interaktionen mit der Datenbasis zu geben. Eine
Transaktion zeichnet sich nach dieser Definition durch vier Eigenschaften aus,
die man auch als ACID-Eigenschaften bezeichnet. Diese Eigenschaften machen
Aussagen "uber das zu beobachtende Verhalten von Transaktionen im Bezug auf
Seiteneffekte. Die Eigenschaften sind:

\paragraph{Atomarit"at:} Die Zustands"anderungen in der Datenbank, die durch die
Transaktion hervorgerufen wurden, sind nach au"sen hin vollst"andig oder gar
nicht sichtbar. Zur Wahrung dieser Eigenschaft existiert ein Mechanismus in
Datenbanksystem, mit dem bei einem Systemfehler, der einen Absturz des DBMS und
des ganzen Systems zur Folge hat, alle Zustands"anderungen seit dem letzten
Transaktionsabschlu"s
automatisch r"uckg"angig gemacht werden. Die M"oglichkeit zu einem
solchen Verhalten wird dem Transaktionsprogrammierer auch als Mittel zur
Fehlerbehandlung in Form der {\sl Rollback}-Anweisung explizit zur Verf"ugung
gestellt.

\paragraph{Konsistenz:}
Ausgehend von einem konsistenten Zustand der Datenbasis f"uhrt
eine vollst"andige Transaktion zu einem neuen aber nach wie vor konsistenten
Zustand. Hierbei mu"s erw"ahnt werden, da"s der Konsistenzbegriff ein rein
datenspezifischer ist und die Konsistenz der "Anderungen durch eine
Transaktion auch nur durch von der Semantik der Daten abh"angige
Pr"ufungen sichergestellt werden
kann. Das Transaktionskonzept selbst besch"aftigt sich nicht mit der Semantik
der zu verwaltenden Daten. Es existieren auch sogenannte aktive
Datenbanksysteme (sieh zum Beispiel \cite{McDa89,SHH87}),
die die Definition konsistenzerhaltender Regeln
erlauben. Diese k"onnen dann zum Transaktionsende "uberpr"uft werden und u.U.
den Abbruch einer konsistenzverletzender Transaktions bewirken.
Es soll hier festgehalten werden, da"s die Konsistenzpr"ufung keine essentielle
Funktionalit"at einer Implementierung von transaktionalen Eigenschaften ist und
oft unabh"angig von diesen implementiert wird.

\paragraph{Isolation:}
Eine einzelne Transaktion sieht die Datenbasis so, als ob sie der
alleinige Benutzer w"are. Anders ausgedr"uckt: eine Transaktion nimmt selber
das Vorhandensein anderer, parallel ablaufender Transaktionen nur bedingt war.
Eine Transaktion sieht zwar die Effekte (erfolgreich) abgeschlossener
Transaktionen, aber nicht solcher, die parallel ablaufen. Die
Isolationseigenschaft erleichtert in gro"sem Ma"se die Aufgabe des
Transaktionsprogrammierers, da dieser sich nicht mit den komplexen und
mannigfaltigen Interaktionsm"oglichkeiten nebenl"aufiger Zustands"anderungen
auseinandersetzen mu"s, sondern die Transaktionen so programmieren kann, als ob
diese in einem Einbenutzersystem ausgef"uhrt w"urden. W"aren nebenl"aufige
Transaktionen nicht voneinander isoliert, w"urden diese z.B. auch inkonsistente
Zust"ande der Datenbasis sehen k"onnen und entsprechend darauf reagieren
m"ussen.

\paragraph{Dauerhaftigkeit:}
Die Seiteneffekte einer erfolgreich abgeschlossenen
Transaktion m"ussen dauerhaft gespeichert und auch gegen Fehler gesch"utzt sein.
In dieser Forderung dr"uckt sich aus, da"s es sich bei Datenbanksystemen um
persistente Systeme handelt, die auch noch speziellen
Fehlertoleranzanforderungen gen"ugen m"ussen. Durch die Zusicherung der
Dauerhaftigkeit wird der Programmierer von der Aufgabe entlastet, die
"Anderungen durch eigens zu spezifizierende Ma"snahmen selber persistent zu
machen; hierdurch wird wieder die Komplexit"at der Programmiert"atigkeit
reduziert.  Durch Dauerhaftigkeit wird aber auch der Aspekt der Fehlertoleranz
eingebracht, weil die gespeicherten "Anderungen auch gegen Folgefehler
gesch"utzt sein m"ussen, die lange nach Beendigung der Transaktion auftreten
k"onnten. Die Behandlung solcher Fehler liegt nat"urlich nicht im
Einflu"sbereich der Transaktion, da diese zu dem Zeitpunkt nicht mehr
existiert; folglich kann diese Fehlertoleranz nur eine Eigenschaft des DBMS
sein. 

Zusammengefa"st kann man sagen, da"s das Transaktionskonzept mehrere
Aspekte in sich vereint:
\begin{itemize}
\item Die Nebenl"aufigkeit bei der Nutzung gemeinsamer Datenbest"ande wird
durch Transaktionen maskiert, und ein Sonderverhalten, welches aus dem
Vorhandensein von Nebenl"aufigkeit entsteht, wird ausgeschlossen. Die
Nebenl"aufigkeit wird dabei nicht vollst"andig ausgeschlossen, sondern nur
durch die Forderung der Transaktion nach Serialsierbarkeit eingeschr"ankt.
\item Der Programmierer kann Transaktionen als Programmierkonstrukt mutzen, um
die Komplexit"at seiner Anwendungen zu reduzieren. Beispielsweise erlaubt die
{\sl Rollback}-Anweisung ein kontrolliertes Zur"ucksetzen des
Datenbankzustandes auf einen fr"uheren konsistenten Zustand, was die Behandlung
semantischer Fehler und Ausnahmesituationen sehr erleichtert. Die 
implizite Persistenz der "Anderungen beim
Transaktionsende nehmen dem Programmierer ebenfalls Arbeit ab.
\end{itemize}

Diese Aspekte verlieren teilweise an Bedeutung, wenn man von einem
Mehrbenutzer-DBMS in den Kontext einer persistenten Programmiersprache
"ubergeht. Der wichtigste Punkt ist, da"s es in persistenten
Programmiersprachen eine anderer Form von Nebenl"aufigkeiten gibt als in DBMS.
In DBMS geht man von dem Vorhandensein mehrere konkurrierender Transaktionen
aus: die Transaktionen bearbeiten nicht in kooperativer Weise dieselbe
Aufgabenstellung, sondern jede Transaktion hat eine eigene Aufgabe und
ben"otigt zu ihrer Bearbeitung Ressourcen, die sie sich mit anderern
Transaktionen teilen mu"s. In persistenten Programmiersprachen hingegen
existiert dieses Konzept der konkurrierenden, nebenl"aufigen Prozesse nicht:
wenn auf demselben System zwei Prozesse dasselbe Programm ausf"uhren, wird
jeder der Prozesse mit seiner eigenen Kopie der Programmvariablen ausgestattet.
Demhingegen kann ein Programm mehrere Threads
beinhalten, die parallel auf dieselben Ressourcen zugreifen k"onnen; dies
geschieht allerdings oft in kooperativer Form.
Hierf"ur w"are aber das Isolationsprinzip nicht passend, weil zur Kooperation
der Threads eine Durchbrechnung der Isolation teilweise unumg"anglich
ist. F"ur eine Unterst"utzung der Programmierung von Transaktionen mit internem
Parallelismus w"are also eine kontrollierte Aufgabe der Isolation erforderlich,
wie sie von erweiterten Transaktionsmodellen, die speziell Parallelit"at
ber"ucksichtigen, angeboten werden. Um das Themengebiet, welches in dieser
Arbeit behandelt wird, "uberschaubar zu halten, habe ich bewu"st diesen Bereich
ausgeklammert und mich auf die Behandlung von persistenten
Einbenutzerprogrammiersystemen beschr"ankt. Das Tycoon-System beinhaltet zwar
Threads, die f"ur die Programmierung paralleler Applikationen genutzt werden
k"onnen, bei der Benutzung transaktionaler Eigenschaften mu"s die
Nebenl"aufigkeit der Threads aber vom Programmierer kontrolliert werden.

Aus dem vorigen Absatz ergibt sich, da"s wir in persistenten
Programmiersprachen auf eine Behandlung der Nebenl"aufigkeit, wie sie in DBMS
zu finden ist, absehen k"onnen. Eine persistente Programmiersprache
soll sich also wie ein Einbenutzer-Datenbanksystem
verhalten. Daraus ergibt sich, da"s Transaktionen in
persistenten Systemen vorwiegend den Aspekt der Komplexit"atsreduzierung f"ur
den Programmierer haben und somit ein Programmierkonstrukt darstellt, welches
innerhalb der Sprache verf"ugbar sein mu"s (in welcher Form wird damit nicht
gesagt). Diese "`Aufgabenreduzierung"' von Transaktionen ist der Grund, warum
diese in persistenten Programmiersprachen
durch weniger als das ACID-Prinzip definiert werden. Die
ACID-Eigenschaften haben in diesem Umfeld folgende Bedeutung:

\paragraph{Atomarit"at:}
Die Zustands"anderungen einer begonnenen Transaktion sollen
weiterhin automatisch durch das System zur"uckgenommen werden, wenn die
Transaktion durch einen Fehler unterbrochen wird. Ebenso wird gefordert, da"s
der Programmierer die M"oglichkeit hat, selber das Zur"ucksetzen
(z.B. als Reaktion
auf einen Fehler) zu initiieren. Diese letzte M"oglichkeit der vereinfachten
Fehlerbehandlung wurde schon als ein f"ur Workflows
wichtiges Merkmal von Transaktionen
angesprochen und wird bei der sp"ateren Auswahl eines 
Transaktionsmodells eine wichtige Rolle spielen.
Bei Verwendung eines offenen persistenten Systems, welches die Benutzung von
extern verwalteten Ressourcen zul"a"st, mu"s
sichergestellt werden, da"s alle von einem Programm angesprochenen Daten in
diesem Rollback-Mechanismus eingeschlossen sind. Bei Datenbanksystemen
als externen Ressourcenmanager kann man sich leicht
vorstellen, da"s sich die Rollbackf"ahigkeit nach au"sen tragen l"a"st.
Dies soll aber auch f"ur solche
Ressourcen gelten, die noch nicht mit transaktionalen Eigenschaften
ausgestattet sind. Dadurch ergibt sich die
gr"o"stm"ogliche Vereinfachung f"ur den Programmierer und M"achtigkeit des
Rollback-Mechanismus, weil externe Daten nicht einer aufwendigen
Sonderbehandlung bed"urfen. Ob und wie dieser Aspekt des transaktionalen
Verhaltens herstellbar ist wird in den Kapiteln~\ref{oplog-kap}
und~\ref{extern-ta-kap} n"aher erl"autert.

\paragraph{Konsistenz:} Auch in persistenten Programmiersprachen
ist die Konsistenzeigenschaft von der
Semantik der Daten bestimmt. Das System kann aber M"oglichkeiten der
Validierung wie z.B. durch Zusicherungen (Ref Ingrid?)
zur Verf"ugung stellen, die vom
Applikationsprogrammierer genutzt werden. Einige der M"oglichkeiten der
Konsistenzpr"ufung k"onnten auch wie bei aktiven Datenbanksystemen
mit dem Transaktionssubsystem im
Laufzeitsystem der pers. PS zusammenarbeiten.  Die
Durchf"uhrung der Konsistenzpr"ufung kann aber gr"o"stenteils unabh"angig von
dem Transaktionssubsystem geschehen oder kann sehr leicht integriert werden.
Die Konsistenzeigenschaft werden deshalb aus dem Kern
der Transaktionseigenschaften ausgeklammert.

\paragraph{Isolation:} Wie bereits erw"ahnt entf"allt dieser Aspekt f"ur
persistente Programme an sich, da die Aufgabenstellung auf Einbenutzersysteme
beschr"ankt wurde und auch programminterne Nebenl"aufigkeit ignoriert werden
soll. Der Isolationsaspekt ist aber trotzdem von Bedeutung, weil andere,
mittelbar "uber externe Aufrufe verwaltete Daten selbstverst"andlich
von der nebenl"aufigen Ausf"uhrung anderer
Transaktionen betroffen sein k"onnen.
In diesem Fall k"onnen nat"urlich die nebenl"aufigen "Anderungen nicht
ignoriert werden, allerdings k"onnen sie auch nicht von dem persistenten
Programmiersystem
gesteuert werden, da nicht alle Zugriffe auf die externen
Ressourcen "uber das persistente System erfolgen. Demzufolge mu"s die
Isolationseigenschaft f"ur externe Ressourcen von deren Managementsystem
implementiert werden und kann nicht durch Ma"snahmen in dem aufrufenden
persistenten System erreicht werden.

\paragraph{Dauerhaftigkeit:}
Auch in persistenten Programmiersprachen soll gelten, da"s nach erfolgreichem
Abschlu"s einer Transaktion 
der damit erreichte Zustand dauerhaft gemacht wurde
und auch gegen sp"atere Ausf"alle gesch"utzt ist.\footnote{Der
Schutz gegen sp"atere
Ausf"alle kann in einfachster Weise durch das Anfertigen von Bandsicherungen
der persistenten Daten des Systems gemacht werden.
Hochgeschwindigkeits-Datenbanksysteme
sehen hier zwar noch andere Mechanismen vor (\cite{Moha92}),
diese werden aber nur
erforderlich, weil diese Systeme sehr gro"sen Durchsatz- und
Verf"ugbarkeitsanforderungen gen"ugen m"ussen. Da wir mit solchen Anforderungen
in persistenten Programmiersystemen selten konfrontiert sind, wollen wir diese
gesonderten Fehlertoleranzmechanismen vernachl"assigen.}
Bei Betrachtung eines offenen persistenen Systems
f"allt auf, da"s die Dauerhaftigkeit auch
auf extern angelegte und verwaltete Daten ausgedehnt werden mu"s, wenn der
vollst"andige Ausf"uhrungszustand persistent gemacht werden soll. Dies ist eine
nicht-triviale Aufgabe f"ur das Transaktionssubsystem eines offenen 
persistenten Programmiersystems,
weil fl"uchtige Daten zu den genutzten externen Ressourcen z"ahlen.

Zusammenfassend kann also folgendes "uber die Rolle und Auswirkung von
Transaktionen in persistenten Programmiersprachen gesagt werden:
\begin{itemize}
\item Transaktionen sollen ein Programmierkonstrukt in der Programmiersprache
sein, welches die
Markierung konsistenter Zust"ande erlaubt und dem Programmierer gestattet, bei
Auftreten von Fehler oder auch sonst unter Umgehung des normalen
Kontrollflusses auf diese markierten Zust"ande zur"uckzuspringen. Durch so
einen R"ucksprung wird der normale Kontrollflu"s durchbrochen, weil der
gesamte Ausf"uhrungszustand des Prozesses einschlie"slich dessen Position
im Code zur"uckgesetzt wird. 
\item
Transaktionen stellen eine Systemeigenschaft dar, die Persistenz beinhaltet
und um den Atomarit"atsbegriff erweitert. Praktisch hei"st das, da"s bei
Neustart eines persistenten Prozesses automatisch der Zustand des letzten
Synchronisationspunktes wiederhergestellt werden mu"s.
\item Die Transaktionseigenschaften m"ussen sich auf alle von einem Programm
bearbeiteten Ressourcen beziehen. Demzufolge m"ussen durch Transaktionen auch
konsistente externe Zust"ande markiert werden k"onnen und beim Zur"ucksetzen
mu"s der externe Zustand wiederhergestellt werden.
Ebenso mu"s die Persistenz der externen
Daten zum Zeitpunkt des Transaktionsendes vom persistenten Programmiersystem
sichergestellt werden.
\end{itemize}
Diese Charakterisierung von Transaktionen in persistenten Programmiersprachen
soll im folgenden als
Definition und Aufgabenzettel bei der Implementierung dienen.
Bisher wurde bewu"st darauf verzichtet, auf ein bestimmtes
Transaktionsmodell bezug zu nehmen;
die bisherigen Aussagen, die "uber
Transaktionen getroffen wurden, gelten unabh"angig von einem bestimmten
Transaktionsmodell. Wie die genaue Form eines Transaktionsmodelles
f"ur Workflows aussehen soll, ist Bestandteil des n"achsten Abschnittes. 

\section{M"oglichkeiten der transaktionale Strukturierung von
Programmen}

Bei der Auswahl eines
Transaktionsmodelles m"ussen Faktoren wie die Funktionalit"at gegen die durch
Workflows gegebenen Rahmenbedingungen (Verteilung und Ber"ucksichtigung von
existierender Infrastruktur) abgewogen werden. Dieses wird dazu f"uhren,
funktional m"achtigere Modelle, die aber nicht in die bestehende Infrastruktur
integriert werden k"onnen, verworfen werden m"ussen. Stattdessen wird sich
herausstellen, da"s eine einfache Erweiterung von flachen Transaktionen um
persistente Sicherungspunkte bereits eine ausreichende M"achtigkeit mit sich
bringt und auf der anderen Seite noch implementierbar ist.

Bevor man ein optimales Transaktionsmodell f"ur Workflows ausw"ahlt, mu"s man
sich fragen, welche qualitativen Unterschiede zwischen den Modellen bestehen
und welche Aspekte der Modelle die f"ur Workflows ben"otigte Funktionalit"at
beeinflussen. Allen
Transaktionsmodellen ist in irgendeiner Form gemeinsam, da"s sie Daten
dauerhaft speichern und Zustands"uberg"ange atomar machen; wie sich dies
in persistenten Programmiersprachen auswirken soll wurde
bereits im vorangegangenen Abschnitt
festgelegt. Worin sich Transaktionsmodelle aber unterscheiden sind die
M"oglichkeiten zur Strukturierung der Transaktionen, insbesondere spielen die
M"oglichkeiten zum Setzen von {\em Synchronisationspunkten} eine entscheidende
Rolle. Unter Synchronisationspunkten sollen die innerhalb einer Transaktion
gesetzten Markierungspunkte zu verstehen sein, auf die mit Hilfe einer {\sl
Rollback}-Anweisung zur"uckgesprungen werden kann. Ein Extrembeispiel sind
die klassischen, flachen
Transaktionen, die zu jedem Zeitpunkt die Existenz von nur einem
Synchronisationspunkt, dem Transaktionsanfang,
unterst"utzen. Ein anderes Beispiel sind geschachtelte
Transaktionen, die mit jeder neuen Subtransaktion einen neuen
Synchronisationspunkt
festlegen. Da ein Bestandteil von transaktionalen Systemen die F"ahigkeit zum
Zur"ucksetzen ist, bestimmen die M"oglichkeiten f"ur das Setzen von
Synchronisationspunkten die Flexibilit"at des Programmierers. Gibt es keine
Einschr"ankungen bzgl.  der M"oglichkeiten f"ur
Synchronisationspunkte,
kann u.U. besser auf Fehlersituationen 
reagiert werden, weil es einen Synchronisationspunkt gibt, der genau diese
Fehlersituation zur"ucknimmt, aber nicht mehr.
Transaktionsmodelle unterscheiden sich auch in den M"oglichkeiten zum
intra-transaktionalen Parallelismus, was jedoch wegen der Einschr"ankung der
Aufgabenstellung auf nicht-parallele Transaktionen nicht weiter verfolgt wird.

Die einfachste M"oglichkeit zur transaktionalen Unterst"utzung besteht in der
Verwirklichung eines Workflows durch genau eine flache Transaktion.
Bereits in der fr"uhesten
Literatur "uber Transaktionen (\cite{Gray81}) ist zu lesen, warum 
eine solche Strukturierung f"ur Workflows ungeeignet ist;
der Vollst"andigkeit halber soll hier die in der Einleitung
skizzierte Argumentation einmal
ausgef"uhrt werden.
Bei flachen Transaktionen dient nur der Transaktionsanfang als
Synchronisationpunkt, demzufolge wird die Transaktion nach beim Wiederanlauf
nach einem Ausfall abgebrochen. Dadurch geht die gesamte innerhalb der
Transaktion verrichtete Arbeit verloren, was f"ur Workflows unakzeptabel ist.
Ebenfalls stellt das Zur"ucksetzen
kein nutzenbringendes Konstrukt mehr dar, weil ebenfalls nur
auf den Transaktionsbeginn gesprungen werden kann. Bezieht man noch extern
vorliegende und transaktional verwaltete Ressourcen mit ein, st"o"st man auch
auf Schwierigkeiten, weil zur Wahrung der Isolationseigenschaften z.B. in
Datenbanken Sperren bis zum Transaktionsende gehalten werden. Entsprechend der
Transaktionsdauer m"ussen die Sperren dann sehr lange gehalten werden, was den
Fortschritt parallel ablaufender Transaktionen stark behindern kann.

Diese Argumente lassen erkennen, da"s es essentiell ist, im Verlauf
eines Workflows
eine beliebige Anzahl von Synchronisationspunkten setzen zu k"onnen.
Einerseits l"a"st sich so der Arbeitsverlust bei einem Systemausfall gering
halten, wenn man davon ausgeht, da"s die Sicherungspunkte auch gleichzeitig als
Aufsetzpunkte beim Wiederanlauf dienen. Andererseits ist eine Vielzahl von
Sicherungspunkten f"ur den effektiven Einsatz der {\sl Rollback}-Anweisung zur
Fehlerbehandlung notwendig. Die einfachste M"oglichkeit, der Anforderung nach
einer beliebigen Anzahl von Synchronisationspunkten in einem Workflow
nachzukommen, besteht in der Partitionierung eines Workflows in flache
Transaktionen. Ein Synchronisationspunkt kann gesetzt werden, indem die
aktuelle Transaktion abgeschlossen und nahtlos im Anschlu"s 
eine neue begonnen wird. Mangelhaft an diesem Modell von "`verketteten"'
Transaktionen ist die
fehlende Flexibilit"at des R"ucksetzmechanismus, der nur ein R"ucksetzen auf
den letzten etablierten Synchronisationspunkt erlaubt. Grund daf"ur ist die
Garantie des flachen Transaktionsmodells, da"s alle Zustands"anderungen einer
abgeschlossenen Transaktion dauerhaft sind,\footnote{Diese Aussage gilt
nat"urlich nur f"ur den Fall, da"s die Zustands"anderungen nicht explizit
r"uckg"angig gemacht werden.} so da"s ein
Zur"ucksetzen "uber das letzte Transaktionsende untersagt werden mu"s.
Warum der Programmierer an einer R"ucksetzm"oglichkeit auf jeden
Synchronisationspunkt
innerhalb des aktuellen Workflows
interessiert sein wird, zeigt folgendes Beispiel
der Buchung einer Reise, die aus mehreren
Einzelaktivit"aten besteht: Flugbuchung, Buchung des Hotels, Reservierung
einer Opernkarte
etc. Wurden Flug und Hotel bereits gebucht (als Einzelaktivit"aten
in bereits abgeschlossenen Transaktionen), und schl"agt jetzt die n"achste
Einzelaktivit"at in der Kette, die Reservierung von Opernkarten, fehl, gibt
es mehrere M"oglichkeiten, darauf zu reagieren. Beispielsweise kann
der letzte Reservierungsversuch
einfach abgebrochen werden und anschlie"send wird
fortgefahren, als ob nichts geschehen sei; dies kann ad"aquat durch verkettete
flache Transaktionen unterst"utzt werden. Eine plausiblere Variante ist aber,
da"s die Reise verschoben wird (falls der Zweck der Reise der Opernbesuch
war), wozu sowohl die Hotelbuchung als auch die Flugbuchung erstmal storniert
und anschlie"send mit ver"andertem Datum wiederholt werden m"ussen. Es ist
w"unschenswert, dies automatisch vom System durch ein Zur"ucksetzen auf
den entsprechenden, vom Programmierer gesetzten Synchronisationspunkt
durchf"uhren zu lassen.

Eine L"osung f"ur diesen letzten Fall stellt die Partitionierung einer
Transaktion durch Sicherungspunkte dar, wobei ein Workflow wieder genau einer
Transaktion entspr"ache.  Eine Transaktion kann eine beliebige
Anzahl von Sicherungspunkte enthalten, die vom Programmierer gesetzt werden und
zur Identifikation vom System eine individuelle Kennung erhalten. Anhand dieser
Kennung kann das Programm ein Zur"ucksetzen auf einen Sicherungspunkt
veranlassen. Mit dem Beenden einer Transaktion werden die bis dahin gesetzten
Sicherungspunkte ung"ultig, so da"s kein Zur"ucksetzen einer bereits
abgeschlossenen Transaktion mehr m"oglich ist und auch die Dauerhaftigkeit
gewahrt bleibt.  Sicherungspunkte sind schon seit geraumer Zeit in
Datenbanksystemen implementiert (\cite{Astr79}),
unter anderem weil die flexibere M"oglichkeit zum
Zur"ucksetzen auch die Implementierung von Datenbanksystemen
vereinfacht: das Datenbanksystem setzt
automatisch vor jedem neuen Befehl einen Sicherungspunkt, so da"s bei einem
Fehler nur der letzte Befehl zur"uckgenommen werden mu"s und nicht 
die gesamte Transaktion.

Sicherungspunkte unterscheiden sich von Synchronisationspunkten, weil mit
Sicherungspunkten nicht der Systenzustand dauerhaft gemacht wird und sie
demzufolge nicht beim Wiederanlauf angesteuert werden k"onnen. Dies hat zur
Folge, da"s bei einem Systemfehler die aktuelle Transaktion automatisch
zur"uckgesetzt wird und alle bisher durch sie ausgef"uhrten "Anderungen
verloren sind. Um diesen Mangel zu beheben, m"ussen die Sicherungspunkte
persistent gemacht werden, so da"s sie nunmehr vollwertige
Synchronisationspunkte sind.
Das System wird beim Wiederanlauf den chronologisch j"ungsten
Synchronisationspunkt
ansteuern, wobei es sich jetzt auch um einen Sicherungspunkt handeln kann. Mit
persistenten Sicherungspunkten bleibt also die Flexibilit"at von
nicht-persistenten Sicherungspunkten erhalten und man hat zus"atzlich die
Ausfallsicherheit von verketteten Transaktionen hinzugewonnen.

Der Einsatz von persistenten Sichronisationspunkten
sei noch einmal am vorigen Beispiel
der Reisebuchung anschaulich gemacht. Um jeden einzelnen Arbeitsabschnitt zu
sichern und die M"oglichkeit zu erhalten, dessen "Anderungen zur"uckzusetzen,
w"urde der Programmierer nach dem erfolgreichen Abschlu"s eines Schrittes einen
Sicherungspunkt setzen. Um zum Beispiel zur"uckzukehren: es w"urden nach der
Flug- und Hotelbuchung jeweils ein Sicherungspunkt
gesetzt werden. Tritt nun ein
Systemfehler w"ahrend der Kartenreservierung auf, hat dies auf die G"ultigkeit
der Flug- und Hotelbuchung keinerlei Auswirkungen. Beim Wiederanlauf w"urde
direkt nach dem letzten vorhandenen Sicherungspunkt, also nach der Hotelbuchung,
fortgefahren werden und der Benutzer m"u"ste die Kartenreservierung
wiederholen. Schl"agt dies fehl, weil die gew"unschte Vorstellung schon
ausgebucht ist, kann z.B. nur die Kartenreservierung abgebrochen werden oder
aber auch die Hotelbuchung (oder die Hotel- und Flugbuchung) storniert werden.

Wie man an dem Beispiel 
sieht, erreicht man mit dieser einfachen Erweiterung von flachen
Transaktionen bereits einen hohen Grad an Ausfallsicherheit und Flexibilit"at
in bezug auf die R"ucksetzm"oglichkeiten.
Was zus"atzlich f"ur dieses Transaktionsmodell spricht ist seine leichte
Erlernbarkeit. Da es sich hierbei um eine Erg"anzung von flachen Transaktionen
handelt, die durch die starke Verbreitung kommerzieller Datenbanksysteme
einen weiten
Bekanntheitsgrad haben, kann der Programmierer sein vorhandenes Wissen
weiterhin einsetzen und mu"s es nur um einige Details erg"anzen. Selbst dies
wird selten notwendig sein, da viele Datenbanksysteme
Sicherungspunkte auf Anwenderebene zur Verf"ugung stellen, und diese sich 
in ihrer Handhabung nicht von persistenten Sicherungspunkten unterscheiden.
Ein weiterer hervorzuhebender Punkt ist, da"s persistente Sicherungspunkte in
einer offenen persistenten Programmiersprache auch im Hinblick auf die
Einbindung externer transaktionaler Ressourcen implementierbar sind.

Die Problematik bei der Einbindung externer transaktionaler Dienste ist, da"s
diese oft nur flache Transaktionen unterst"utzen; Sicherungspunkte m"ogen zwar
vorhanden sein, aber diese sind nicht persistent und deshalb auch nicht weiter
verwertbar. Unser Ziel ist es, eine integrierte persistente
Entwicklungsumgebung zur Verf"ugung zu stellen, in der externe Dienste
transparent und uneingeschr"ankt innerhalb des Transaktionsmodells eingesetzt
werden k"onnen.  Um also das Verhalten von persistenten Sicherungspunkten
in transaktionalen externen Diensten zu simulieren, mu"s eine Anpassung
vorgenommen werden. Die Anpassung sieht so aus, da"s f"ur jeden Sicherungspunkt
die extern ausgef"uhrte Transaktion abgeschlossen und eine neue begonnen wird,
wodurch man extern wieder eine Transaktionskette f"ur einen einzelnen Workflow
erh"alt. Ein Beispiel f"ur dieses Vorgehen ist in
Abbildung~\ref{ta-umsetzung-fig} zu sehen.
Wenn innerhalb des Programms auf einen Sicherungspunkt
zur"uckgesprungen wird, m"ussen extern die abgeschlossenen Transaktionen durch
geeignete Ma"snahmen kompensiert werden.
\begin{figure}[tb]
%\leavevmode
\def\epsfsize#1#2{1.0\textwidth}
\centerline{\epsffile{internta.eps}}
\caption{\label{ta-umsetzung-fig} Beispiel f"ur die externe Umsetzung von
Sicherungspunkten}
\end{figure}

Der vorangegangene Vergleich der transaktionalen Strukturierungsm"oglichkeiten
von Workflows hat gezeigt, da"s flache Transaktionen mit persistenten
Sicherungspunkten die funktionalen Anforderungen von Workflows---M"oglichkeiten
zum Sichern von Zwischenzust"anden und flexible Reaktionsm"oglichkeiten auf
Fehler---bereits erf"ullen. Der folgende Abschnitt zeigt, wie persistente
Sicherungspunkte dem Programmierer in Tycoon zur Verf"ugung stehen und spricht
Aspekte der Implementierung als Vorbereitung auf die n"achsten Kapitel an.

\section{Ein Transaktionsmodell f"ur Tycoon basierend auf persistenten
Sicherungspunkten}
\label{ta-modell-sec}

Zentrale Philosophie von Tycoon ist die Erweiterbarkeit des Systems durch
benutzergeschriebene Module. Die von diesen Modulen exportierten neuen
Datentypen und zugeh"orige Operationen lassen sich "uber das polymorphe
Typsystem nahtlos in die bestehende Umgebung integrieren, so da"s die
Grenze zwischen eingebauter und erweiterter Funktionalit"at verschwimmt. 
Da die Implementation eines Moduls auch Aufrufe an das Tycoon-Laufzeitsystem
zul"a"st, ist es naheliegend, die transaktionalen Befehle wie "ublich "uber
eine Modulschnittstelle dem Programmierer anzubieten. So etwas "ahnliches ist
bereits mit dem Modul {\sl checkpoint}, einem Modul f"ur flache Transaktionen,
in Tycoon realisiert und wird als
Ausgangsbasis f"ur die Gestaltung eines neuen Moduls {\sl transaction}
f"ur Transaktionen mit persistenten Sicherungspunkten dienen.

Das Modul {\sl transaction} bildet die Schnittstelle zum erweiterten
Transaktionsmechanismus in Tycoon; das Definitionsmodul ist in
Abbildung~\ref{transaction-fig} zu sehen. Genau wie vorher befindet sich auch
unter dem erweiterten Transaktionskonzept ein Tycoon-Proze"s zu jedem Zeitpunkt
in genau einer Transaktion, deren Verlauf durch die von {\sl transaction}
exportierten Funktionen gesteuert wird. Die Funktionen {\sl commit()} und {\sl
rollback()} haben dieselbe Bedeutung wie die namensgleichen Funktionen des
Moduls {\sl checkpoint}: durch sie wird die aktuelle Transaktion abgeschlossen
bzw. abgebrochen und unmittelbar eine neue Transaktion gestartet. Zum Setzen
eines Sicherungspunktes dient die Funktion {\sl savepoint()}, die dessen
Systemkennung in Verbindung mit einem Statuswert zur"uckliefert. Der Statuswert
teilt dem Programm mit, wie der Aufruf erreicht wurde: durch das urspr"ungliche
Setzen, durch ein Zur"ucksetzen oder durch einen Wiederanlauf. Derselbe
Statuswert wird auch von der Funktion {\sl commit()} zur"uckgegeben. Die
Kennung eines Sicherungspunktes dient als Parameter der Funktion {\sl
rollbackTo()}, mit der das Zur"ucksetzen auf den entsprechenden Sicherungspunkt
veranla"st wird. Die Funktion {\sl rollbackToLast()} f"uhrt ein Zur"ucksetzen
auf den letzten Sicherungspunkt durch bzw. bricht die Transaktion ab, wenn noch
kein Sicherungspunkt gesetzt wurde. Sie dient nur als Vereinfachung gegen"uber
{\sl rollbackTo()}, weil sie keine Kennung des Sicherungspunktes als Parameter
erfordert.
Da sich ein Programm zu jedem Zeitpunkt in einer Transaktion befindet, ist
keine Funktion notwendig, die explizit die Transaktionseigenschaften
"`einschaltet."' Die M"oglichkeit zum Ein- und Ausschalten transaktionalen
Verhaltens mag auf den ersten Blick gewinnbringend aussehen, weil so der durch
die transaktionalen Eigenschaften erforderliche Zusatzaufwand nach Bedarf
umgangen werden kann. Diese M"oglichkeit f"uhrt aber auch leicht zu
Inkonsistenzen und schwer zu durchschauenden Programmierfehlern, so da"s auf
sie verzichtet wurde. Kapitel~\ref{intern-kap} wird auch zeigen, da"s der mit
Transaktionen verbundene Zusatzaufwand sich in ertr"aglichen Grenzen h"alt.
\begin{figure}[tb]
\begin{xple}
\kw{interface} Transaction

\kw{export}

  Via $<$:\kw{Ok}

  Savepoint $<$: \kw{Ok}

  error :\kw{Exception}

  commitVia, rollbackVia, restartVia :Via

  savepoint() :\kw{Tuple} s :Savepoint v :Via \kw{end}

  commit() :Via

  rollbackTo(s :Savepoint) :\kw{Ok}

  rollbackToLast() :\kw{Ok}

  rollback() :\kw{Ok}

\kw{end};
\end{xple}
\caption{\label{transaction-fig}
Die Schnittstelle des Moduls {\sl transaction}.}
\end{figure}

F"ur den Programmierer stellen sich also persistente Sicherungspunkte
als simple Erweiterung des
bestehenden Transaktionsmechanismus in Tycoon dar, bei der nur
zwei\footnote{W"urde man auch die Funktion {\sl rollbackToLast()}
einrechnen, w"aren es drei Funktionen.}
Funktionen zus"atzlich hinzukommen. Anders als bisher 
 sollen aber Transaktionen nicht nur
f"ur Tycoon-eigene Daten verantwortlich sein, sondern insbesondere auch die
extern angesteuerten Daten miteinbeziehen. Bei Workflows stellen im allgemeinen
die externen Daten die Nutzdaten dar, die zudem aus einer Vielzahl externen
Systeme stammen. Als Beispiel wurden in den vorangegangenen Abschnitten schon
mehrfach Datenbanksysteme angef"uhrt, denen oft die zentrale Rolle bei der
Datenspeicherung zukommt. Aber auch die Elemente einer graphischen
Benutzeroberfl"ache, beschriebene Dateien, angesprochene Drucker und aufgebaute
Netzwerkverbindungen sind Beispiele f"ur h"aufig eingesetzte externe
Ressourcen. Diese Liste kann noch beliebig fortgesetzt werden; die Menge der
f"ur Workflows relevanten und deshalb in den Transaktionsmechanismus zu
integrierenden externen Ressourcen ist also unbeschr"ankt. Erschwerend kommt
hinzu, da"s diese Ressourcen teilweise sehr unterschiedliche Charakteristiken
aufweisen. Beispielsweise sind Ressourcen wie die Elemente graphischer
Benutzeroberfl"achen fl"uchtig und m"ussen demzufolge auch anders behandelt
werden als Datenbanken. Da es
unm"oglich ist, f"ur jeden einzelnen Datentyp eigene transaktionale Algorithmen
zu implementieren---dieses ist nicht nur unwirtschaftlich, sondern stellt die
Erweiterbarkeit des Systems in Frage---mu"s nach
Unterscheidungsmerkmalen gesucht werden, anhand derer sich die Datentypen 
kategorisieren lassen. Das Ziel ist, da"s die Datentypen einer Kategorie mit
denselben Verfahren in den Transaktionsmechanismus integriert werden k"onnen.
Folgende drei Merkmale lassen sich dabei als entscheidend erkennen:
\begin{description}
\item[Herkunft] Bei den Daten kann es sich sowohl um Tycoon-interne Werte als
auch um extern erzeugte handeln.  Dieser
Aspekt ist sehr wichtig f"ur die transaktionalen Verfahren, weil "uber
externe Daten weit weniger Information vorliegt als "uber interne, und somit
auch die M"oglichkeiten eingeschr"ankt sind.
Da externe Dienste nur "uber ihre Schnittstellen bekannt sind, l"a"st sich der
Zustand externer Ressourcen im Regelfall nur durch die Sequenz der darauf
ausgef"uhrten Operationen darstellen.  Eine transaktionale Behandlung
externer Daten wird also zwangsweise auf der Sequenz der ausgef"uhrten
Operationen aufbauen m"ussen.
Demgegen"uber k"onnen
Tycoon-Werte u.U. optimiert behandelt werden, weil von diesen auch die
interne Darstellung einsehbar ist.
\item[Transaktionalit"at] Die Verwaltung der Ressourcen kann schon von sich aus
die transaktionalen Eigenschaften zusichern, wie es z.B. f"ur die
Tycoon-internen wie auch einige externe Daten der Fall ist. Bei externen Daten
ist zu beachten, da"s Persistenz nicht mit transaktionalem Verhalten
gleichgesetzt werden kann, wie das Beispiel von Betriebssystemdateien
belegt.\footnote{Eine Ausnahme stellt Tandems {\em Guardian}-Betriebssystem dar,
das mit einem transaktionalen Dateisystem ausgestattet ist.}
Werden mehrere transaktional verwaltete Ressourcen in einen Workflow
einbezogen, mu"s das Setzen von Synchronisationspunkten zwischen den
entsprechenden Ressourcenmanagern mit Techniken der verteilten
Transaktionsverarbeitung synchronisiert werden.\footnote{Die Begr"undung dieser
Aussage wird sp"ater in Kapitel~\ref{extern-ta-kap} vorgenommen.}
\item[Persistenz] Weiter oben wurden die Elemente graphischer Oberfl"achen und
Netzwerkverbindungen bereits als Beispiel f"ur nicht-persistente Ressourcen
aufgef"uhrt; Beispiele f"ur persistente "`Daten"' sind Dateien oder auch
Drucker.\footnote{Ein Ausdruck hat einen persistenten Seiteneffekt, n"amlich
das bedruckte Blatt.} Da Persistenz ein Bestandteil der transaktionalen
Eigenschaften ist, mu"s bei fl"uchtigen Daten die Persistenz simuliert
werden.
\end{description}
Die Nutzungsweise der Daten, also ob diese applikations-privat sind oder
geteilt werden, wird als Unterscheidungsmerkmal ignoriert. Wie bereits in
Abschnitt~\ref{ta-eigenschaften-sec} bei der Diskussion transaktionaler
Eigenschaft festgestellt wurde, spielt die Isolationseigenschaft im Kontext
persistenter Programmiersprachen keine Rolle.

Die Klassifizierung von transaktional zu behandelnden Daten ist in Abbildung~\ref{kategorien-fig} als
Entscheidungsbaum dargestellt, der in nur vier Klassen entsprechend
bestimmter Merkmalsauspr"agungen m"undet. Bei orthogonaler Anwendung obiger
Merkmale entst"unden acht Klassen; einige dieser Klassen beruhen aber auf
widersinnigen Merkmalskombinationen. F"ur Tycoon-interne Daten ist es
beispielsweise unsinnig anhand der Art der Verwaltung und Persistenz weitere
Unterscheidungen zu machen, weil in Tycoon orthogonale Persistenz mit flachen
Transaktionen vorgegeben ist. Ebenso ist die Persistenz eine zentrale
Eigenschaft transaktionaler Daten.
\begin{figure}[tb]
\def\epsfsize#1#2{0.7\textwidth}
\centerline{\epsffile{kategorien.eps}}
\caption{\label{kategorien-fig} Die Ressourcenklassifizierung}
\end{figure}
Damit kristallisieren sich vier Klassen von Daten heraus, die zur
Implementierung transaktionalen Verhaltens jeweils spezialisierte Verfahren
ben"otigen.  Als "Ubersicht f"ur die folgenden drei Kapitel sei hier zu jeder
Klasse das Realisationsverfahren angesprochen.

\paragraph{Tycoon-interne Daten:}
In der Architektur von Tycoon ist bereits durch
eine Store-Komponente eine orthogonale, also typunabh"angige und
allumfassende, Persistenz integriert. Ebenso wurde bei der Store-Architektur
die Unterst"utzung flacher Transaktionen ber"ucksichtigt.  Um
persistente Sicherungspunkte
in Tycoon zur Verf"ugung zu stellen, mu"s also die bestehende
Architektur in m"oglichst "`schonender"' Weise erweitert werden, d.h.
ohne 
die Integration des Stores zu beeintr"achtigen. Das unmittelbar anschlie"sende
Kapitel beschreibt eine auf dem Store aufgesetzte Zwischenschicht, die eine
funktionale Erweiterung des Stores um persistente Sicherungspunkte realisiert.

\paragraph{Fl"uchtige externe Daten:}
Bei dieser Klasse von Daten
fehlt selbst die elementare Persistenzeigenschaft, so da"s diese vom System
unter R"uckgriff auf die Sequenz der ausgef"uhrten Operationen simuliert werden
mu"s. Zu diesem Zweck werden die Operationen und die dazugeh"origen
kompensierenden Operationen chronologisch in einer Log-Struktur verzeichnet. 
Wie allgemein bei externen Daten
wird auch hier der Zustand durch Ausf"uhrung
kompensierender Operationen zur"uckgesetzt. Die Wiederherstellung des aktuellen
Zustands wird durch Wiederholung der aufgezeichneten Operationen erreicht.
Kapitel~\ref{oplog-kap} beschreibt die Realisierung des Operations-Loggings
f"ur fl"uchtige Daten.

\paragraph{Transaktionale externe Daten:}
Da bei transaktional verwalteten externen Ressourcen die ben"otigten
Persistenz- und Atomarit"atseigenschaften schon vorhanden sind, geht es nun
darum, diese mit Tycoon in sicherer Weise zu verbinden. Das Ziel ist, die
erweiterte Transaktionssemantik von Tycoon auf die externen Dienste abzubilden
und dabei insbesondere den Zustand von Tycoon und den externen Ressourcen
synchron zu halten. Die Integration erfolgt durch Abbildung von
Sicherungspunkten auf extern abgeschlossene Transaktionen; da hierbei in
mindestens zwei verschiedenen Ressourcen\footnote{Beim Zustand von Tycoon
handelt es sich auch um eine Ressource im Sinne des Transaktionsmodells.}
Zust"ande gesichert werden sollen, mu"s ein zweiphasiges Protokoll ({\em
2-phased Commit}, 2PC) zur Koordination eingesetzt werden. Die zum
Zur"ucksetzen erforderlichen kompensierenden Operationen werden in einer
Log-Struktur verzeichnet.
Kapitel~\ref{extern-ta-kap} geht auf die Architektur einer verteilten
Transaktionsumgebung mit Tycoon ein und schildert den Protokollablauf.

\paragraph{Nicht-transaktionale persistente externe Daten:}
Da bei dieser Art von Daten die Dauerhaftigkeit schon vorhanden ist, mu"s f"ur
die Integration in Tycoon nur die R"ucksetzbarkeit implementiert werden. Genau
wie bei transaktionalen Daten werden auch hier zum Zur"ucksetzen kompensierende
Operationen ausgef"uhrt, die in einer Log-Struktur verzeichnet werden
m"ussen. Die Implementationsdetails der Log-Struktur und des Verfahrens zum
Zur"ucksetzen unterscheiden sich nicht von denen f"ur transaktionale Daten,
weshalb den nicht-transaktionalen persistenten Daten kein eigenes Kapitel
gewidmet ist. Es sei aber noch angemerkt, da"s im Unterschied zu
transaktionalen Daten sich nicht garantieren l"a"st, da"s der externe Zustand
synchron mit Tycoon bei den Sicherungspunkten festgeschrieben wird. Aus diesem
Grund ist die Einbeziehung von nicht-transaktionalen externen Daten mit dem
Risiko m"oglicherweise inkonsistenter Zust"ande verbunden, die durch manuelle
Eingriffe des Benutzers behoben werden m"ussen.
