In klassischen Anwendungen bleibt eine Datenbank-Session häufig so lange an eine Transaktion gebunden, bis diese committed oder zurückgerollt wurde. Bei langen oder pausierenden Workflows blockiert das Connection-Pool-Ressourcen. Sessionless Transactions in Oracle AI Database 26ai erlauben, eine Transaktion mit einer eindeutigen Kennung zu starten, zu suspendieren und später über eine andere Session oder Verbindung fortzusetzen.
1. Transaktion und Session entkoppeln
Der Kern des Modells ist die Trennung von Geschäftsarbeit und physischer Verbindung. Eine Session startet eine Transaktion und führt einen Arbeitsschritt aus. Danach kann die Transaktion suspendiert werden, während die Verbindung in den Pool zurückkehrt. Ein späterer Schritt nimmt dieselbe Transaktion über eine andere Session wieder auf.
Das ist besonders interessant für Workflows, die auf externe Rückmeldungen warten oder mehrere kurze Datenbankaktionen umfassen. Statt eine Session während der gesamten Wartezeit zu reservieren, kann der Pool sie für andere Arbeit verwenden.
2. Eindeutige Identität und Zustandsmodell
Jede Sessionless Transaction benötigt eine eindeutige Transaktionskennung. Diese Kennung gehört in die fachliche Ablaufverfolgung und muss gegen doppelte Starts, falsche Wiederaufnahme und parallele Verarbeitung geschützt werden. Ein Workflow sollte außerdem explizite Zustände wie gestartet, suspendiert, fortgesetzt, committed, rolled back oder abgelaufen führen.
Die Datenbank koordiniert Commit und Recovery intern. Das reduziert die Abhängigkeit von einem externen XA-Transaction-Manager, ersetzt aber nicht die fachliche Fehlerbehandlung. Ein Timeout oder ein verlorener Workflow-Schritt muss weiterhin sichtbar werden und einen definierten Betreiber- oder Kompensationsweg haben.
3. RAC und Connection-Pooling testen
Sessionless Transactions können auf einer Single-Instance-Datenbank und in RAC-Szenarien eingesetzt werden. In RAC kann ein weiterer Arbeitsschritt auf einer anderen Instance fortgesetzt werden. Das macht Tests mit realem Pooling, Rebalancing und Netzwerkausfällen besonders wichtig.
Prüfen Sie, ob der Client-Treiber die benötigten Funktionen unterstützt und wie die Transaktionskennung im Pool weitergereicht wird. Ein Pool darf eine Verbindung nach dem Suspend nicht versehentlich mit einem falschen Transaktionskontext an den nächsten Aufrufer übergeben.
4. Timeout, Monitoring und Recovery
Offene Sessionless Transactions müssen überwacht werden. Relevant sind Alter, Status, Besitzer, letzter Arbeitsschritt und erwarteter nächster Übergang. Eine Transaktion, die länger als fachlich erlaubt suspendiert bleibt, sollte alarmiert und nach Runbook behandelt werden.
Für die Analyse gehören Datenbankmetriken und Anwendungskorrelation zusammen. Transaktions-ID, Request-ID und Service-Name sollten in Logs und Traces auftauchen. Die View V$TRANSACTION_TABLE stellt in 26ai Informationen bereit, mit denen Sessionless Transactions im Datenbankkontext erkannt werden können.
5. Praktische Checkliste
- Workflow, Transaktionsgrenzen, maximale Suspend-Dauer und Abschlussregeln definieren.
- Transaktions-ID sicher erzeugen, speichern und über Service-Grenzen weitergeben.
- Start, Suspend, Resume, Commit, Rollback und Timeout mit dem gewählten Treiber testen.
- Connection-Pool auf korrekte Rückgabe und Wiederaufnahme des Kontextes prüfen.
- RAC-Wechsel, Netzwerkfehler, Prozessabbruch und Wiederanlauf simulieren.
- Offene Transaktionen, Alter, Status und fachliche Korrelation überwachen.
Fazit
Sessionless Transactions in Oracle AI Database 26ai können Connection-Pools entlasten und lang laufende, unterbrechbare Workflows sauberer abbilden. Der Gewinn entsteht durch die Entkopplung von Session und Transaktion; die Betriebsqualität hängt an eindeutigen IDs, getesteten Treibern, Timeouts und sichtbarem Recovery-Verhalten.
Weiterführend: Oracles Leitfaden zu Sessionless Transactions, die OCI-Transaktionsfunktionen und die Neuerungen in Oracle AI Database 26ai.