Viele Transaktionen ändern denselben numerischen Wert: verfügbare Lagerbestände, Kontingente oder ein Guthaben. Klassische Updates blockieren dabei häufig dieselbe Zeile, bis die Transaktion abgeschlossen ist. Oracle AI Database 26ai führt mit Lock-Free Reservation reservierbare numerische Spalten ein, die konkurrierende Erhöhungen und Verringerungen zunächst als Reservierungen behandeln.
1. Geeignete Hot Rows erkennen
Das Muster passt zu Werten, die häufig additiv verändert werden und bei denen viele Transaktionen auf dieselbe Zeile zugreifen. Typische Beispiele sind Bestand, verfügbare Plätze oder ein Budget. Es ist weniger geeignet, wenn Updates komplexe Spaltenbeziehungen verändern oder der gesamte Datensatz gleichzeitig exklusiv geprüft werden muss.
Vor der Modellierung sollte die aktuelle Blockierungsursache gemessen werden: Wartezeiten, Anzahl konkurrierender Sessions, Commit-Dauer und Fehlversuche. Nur wenn die Hot Row tatsächlich der Engpass ist, lohnt die zusätzliche Modelllogik.
2. Reservierbare Spalte und CHECK-Bedingung
Eine reservierbare Spalte wird im Tabellenschema mit RESERVABLE gekennzeichnet und muss einen unterstützten numerischen Datentyp besitzen. Eine CHECK-Bedingung definiert, unter welchen Werten eine Reservierung gültig ist. Für einen Bestand kann beispielsweise festgelegt werden, dass der Wert nicht negativ werden darf.
Die Bedingung sollte fachlich verständlich und möglichst eng sein. Je komplexer die Prüfung, desto wichtiger sind Tests mit mehreren gleichzeitigen Reservierungen, Rollbacks und abgebrochenen Sessions. Die Datenbank muss am Ende einen gültigen Zustand gewährleisten, nicht nur die Wartezeit reduzieren.
3. Was sich bei der Konkurrenz ändert
Bei einer normalen Zeilenänderung wartet eine zweite Transaktion häufig auf den Lock der ersten. Bei einer reservierbaren Spalte werden additive Änderungen als Reservierungsjournal geführt und erst beim Commit in den tatsächlichen Wert überführt. Dadurch können andere Transaktionen weiterarbeiten, sofern die CHECK-Bedingung am Ende erfüllt werden kann.
Nicht reservierbare Spalten derselben Zeile können unter bestimmten Bedingungen ebenfalls weniger durch die Reservierung blockiert werden. Das ist ein Vorteil für gemischte Workloads, darf aber nicht als pauschale Garantie für jede Spaltenkombination verstanden werden.
4. Saga- und Recovery-Szenarien mitdenken
Lock-Free Reservation kann in Microservice- und Saga-Modellen interessant sein, weil Reservierungen über eine Kompensation zurückgenommen werden können. Damit eine fachliche Stornierung korrekt funktioniert, müssen Reservierungs-ID, Teilnehmer, Status und Ausgleichsbetrag nachvollziehbar bleiben.
Betreiber brauchen außerdem ein klares Verfahren für abgebrochene, abgelaufene oder zurückgerollte Transaktionen. Die Frage lautet nicht nur „Ist die Zeile frei?“, sondern auch „Welche fachliche Reservierung ist noch offen und wer darf sie auflösen?“
5. Praktische Concurrency-Checkliste
- Hot Row, Änderungsmuster und erwartete Konkurrenz anhand von Messdaten bestätigen.
- Reservierbare numerische Spalte und fachliche CHECK-Bedingung definieren.
- Gleichzeitige Additionen, Subtraktionen, Commit und Rollback testen.
- Fehlgeschlagene Reservierungen, Savepoints und Sessionabbrüche simulieren.
- Wartezeiten, Commit-Latenz, Fehlerraten und Reservierungsjournal überwachen.
- Bei Sagas Kompensation, Statuswechsel und Recovery im Runbook dokumentieren.
Fazit
Lock-Free Reservation in Oracle AI Database 26ai bietet ein neues Concurrency-Modell für stark umkämpfte numerische Werte. Reservierbare Spalten, CHECK-Bedingungen und Commit-Prüfungen können Blockierungen reduzieren, verlangen aber ein präzises fachliches Modell und belastbare Paralleltests. Besonders in Microservice- und Saga-Abläufen müssen Kompensation und Recovery von Anfang an eingeplant werden.
Weiterführend: Oracles Leitfaden zu Lock-Free Reservation, die CREATE-TABLE-Referenz und die Database-Architecture-Neuerungen.