Was sind ACID-Transaktionen?

Eine ACID-Transaktion ist eine Gruppe von Datenbankoperationen, die als eine Einheit festgeschrieben wird – atomar, konsistent, isoliert und dauerhaft. Die Idee ist älter als das Akronym: Jim Gray definierte die Garantien 1981, Härder und Reuter nannten sie 1983 ACID, und vierzig Jahre später ist sie noch immer der Vertrag, der es erlaubt, Geld in Software zu bewegen, ohne gelegentlich welches zu erfinden oder zu vernichten.

Das Wichtigste in Kürze

Wie ACID-Transaktionen in SQL funktionieren (Beispiel Überweisung)

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE id = 'bob';

-- Absturz oder Fehler zwischen den beiden Updates? Die Engine rollt zurück:
-- ROLLBACK;  →  beide Änderungen verschwinden; kein Geld geht verloren

COMMIT;       -- oder beide werden gültig: atomar und dauerhaft

Anwendungscode begegnet denselben Garantien in kleineren Portionen – atomare Feldoperationen, die das Wettrennen beim Lesen-Ändern-Schreiben beenden, und Batches, die gemeinsam festgeschrieben werden:

// JavaScript / Node.js — Back4app JS SDK
// Atomicity where apps actually need it
counter.increment('sold', 1);        // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// All-or-nothing batch: both rows commit, or neither does
await Parse.Object.saveAll([debitEntry, creditEntry], { transaction: true });

// Flutter / Dart — Back4app Flutter SDK
// Atomicity where apps actually need it
counter.setIncrement('sold', 1);     // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
await ParseObject.saveAll([debitEntry, creditEntry]);

// iOS / Swift — Back4app Swift SDK
// Atomicity where apps actually need it
var updated = counter
updated.sold = (updated.sold ?? 0) + 1
// Prefer the atomic operation over read-modify-write:
let op = counter.operation.increment("sold", by: 1)
op.save { result in
  if case .success = result { print("atomic increment committed") }
}

// Android / Kotlin — Back4app Android SDK
// Atomicity where apps actually need it
counter.increment("sold")            // atomic single-field update — no
counter.saveInBackground()           // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
ParseObject.saveAllInBackground(listOf(debitEntry, creditEntry))

Der Lebenszyklus einer Transaktion: BEGIN, COMMIT und ROLLBACK

Die vier Eigenschaften, jeweils beschrieben durch das, was ohne sie kaputtgeht: Atomarität – ohne sie gibt es halbe Schreibvorgänge (die belastete, aber nie gutgeschriebene Überweisung). Konsistenz – ohne sie gibt es festgeschriebene Zustände, die Ihre eigenen Regeln verletzen (negativer Lagerbestand, verwaiste Referenzen). Isolation – ohne sie lesen gleichzeitige Transaktionen die halbfertige Arbeit der anderen. Dauerhaftigkeit – ohne sie gibt es “festgeschriebene” Daten, die ein Absturz stillschweigend wieder löscht. Unter der Haube liefern drei Mechanismen diese Eigenschaften: Undo-Logs für den Rollback, Write-Ahead-Logging für das Überstehen von Abstürzen und Sperren oder MVCC für die Nebenläufigkeit.

Isolationsstufen vs. Leseanomalien

Die Übersicht, die man sonst selten an einem Ort findet – welche Stufe welche Anomalie verhindert:

Zur Einordnung: Ein Dirty Read sieht noch nicht festgeschriebene Arbeit; ein Non-Repeatable Read erhält auf dieselbe Frage zweimal unterschiedliche Antworten; ein Phantom sieht mitten in der Transaktion neue Zeilen auftauchen. Die meisten modernen Engines arbeiten standardmäßig mit MVCC-basierten Snapshots – jede Transaktion liest einen konsistenten Snapshot, während Schreiber weiterarbeiten –, weshalb “Leser blockieren keine Schreiber” zur Regel statt zur Ausnahme geworden ist.

ACID vs. BASE – und das Homonym Konsistenz

Eine Klarstellung trägt diesen ganzen Vergleich: Das C in ACID und das C in CAP sind verschiedene Wörter mit demselben Buchstaben. ACID-Konsistenz bedeutet, dass jede Transaktion Ihre deklarierten Regeln wahrt. CAP-Konsistenz bedeutet, dass sich alle Knoten genau jetzt einig sind. Eine Datenbank auf einem einzigen Knoten ist vollständig ACID-konform, ohne dass CAP überhaupt ins Spiel kommt; ein verteiltes System wählt seinen CAP-Trade-off und seine Transaktionsgarantien getrennt voneinander.

Wer was garantiert

Verteilte Transaktionen verdienen eine ehrliche Fußnote: Two-Phase Commit (Zwei-Phasen-Commit) erkauft Atomarität über Knoten hinweg mit Latenz und einem blockierenden Koordinator. Deshalb setzen Microservice-Architekturen zunehmend auf Sagas – Folgen lokaler Transaktionen mit kompensierenden Rollbacks, die sofortige Konsistenz gegen Verfügbarkeit tauschen. Wenn ein Workflow Kompensation wirklich nicht verträgt, ist das ein Beleg dafür, dass er in eine einzige Datenbank gehört, nicht über mehrere verteilt.

Typische Anwendungsfälle

• Geldbewegungen. Überweisungen, Auszahlungen, Hauptbücher – der klassische Fall und noch immer der eindeutigste.
• Lagerbestand und Buchungen. Bestand verringern und Bestellung bestätigen, beides gemeinsam – sonst kaufen zwei Kunden den letzten Platz.
• Invarianten über mehrere Zeilen. Bestellung + Positionen, Konto + Audit-Eintrag – Datensätze, die nur gültig sind, wenn sie gemeinsam entstehen.
• Zähler, richtig gemacht. Atomare Inkremente – die kleinste nützliche Dosis ACID – beenden das Wettrennen beim Lesen-Ändern-Schreiben ohne vollständige Transaktionen.
• Die Ergänzung durch Eventual Consistency. Feeds, Likes, Analytics: bewusst weg von den Kosten der Transaktionen geleitet.

Muss es ACID sein? Eine Entscheidungsmatrix

Die Kunst liegt im Routing pro Schreibvorgang: Der Checkout nutzt Transaktionen, der Aufrufzähler ein atomares Inkrement, der Feed verträgt eine Sekunde Abweichung – eine Anwendung, drei Preisstufen für Konsistenz.

Grenzen und Trade-offs

• Koordination ist der Kostentreiber. Sperren konkurrieren, WAL-Syncs gehen auf die Platte, Serializable-Wiederholungen brechen ab – Korrektheit kostet Durchsatz, und genau deshalb gibt es BASE.
• Isolationsstufen sind ein folgenreicher Standard. Die meisten Engines verwenden standardmäßig nicht Serializable; kennen Sie Ihre Stufe, sonst sind Anomalien, die Sie für unmöglich hielten, bloß unwahrscheinlich.
• Lange Transaktionen sind ein Warnsignal. Wer Sperren über die Bedenkzeit von Nutzern oder über Netzwerkaufrufe hinweg hält, macht aus Garantien Konkurrenz um Sperren; halten Sie Transaktionen kurz und entschieden.
• Verteiltes ACID ist von Natur aus teuer. Konsensrunden bei jedem Commit – zahlen Sie das dort, wo Invarianten es verlangen, nicht reflexhaft überall.
• ACID kann Ihre Regeln nicht für Sie validieren. Konsistenz wahrt deklarierte Constraints; Geschäftsregeln, die nie codiert wurden, werden zuverlässig nicht durchgesetzt.

ACID-Transaktionen mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Ihr Transaktionswerkzeug entspricht der Art, wie Apps ACID tatsächlich nutzen: Jeder Schreibvorgang auf ein einzelnes Objekt ist in der zugrunde liegenden Dokument-Engine atomar, atomare Inkremente und Array-Operationen beenden die klassischen Wettrennen bei Zählern (siehe Code-Tabs oben), Batch-Speichervorgänge bündeln Schreibvorgänge, und mehrstufige Invarianten gehören in Cloud Code – serverseitig validiert und ausgeführt, wo ein beforeSave-Trigger jeden Schreibvorgang ablehnen kann, der die Regeln verletzen würde. Die Entscheidungsmatrix ist eingebaut: günstige Atomarität als Standard, volle Koordination dort, wo Sie sie anfordern.