Wie funktionieren Datenbanktransaktionen in Django?

Question

Accepted Answer

Eine **Datenbanktransaction** fasst mehrere Operationen zusammen, sodass sie entweder **alle zusammen erfolgreich sind oder alle zusammen fehlschlagen** (Atomarität) — und verhindert dadurch partielle, inkonsistente Updates. Django stellt `transaction.atomic` bereit, um Operationen in einer Transaction zu wrappen und damit Datenintegrität für mehrstufige Operationen zu gewährleisten.

## Das Problem, das Transactionen lösen

```python
# ❌ WITHOUT a transaction — partial failure leaves inconsistent data
def transfer_money(from_account, to_account, amount):
    from_account.balance -= amount
    from_account.save()                  # ✓ succeeds
    # ...if the server crashes HERE, money vanished from one account...
    to_account.balance += amount
    to_account.save()                    # ✗ never runs → money LOST!
```

Ohne eine Transaction: Wenn die zweite Operation fehlschlägt, ist die erste bereits committed — und die Datenbank wird in einem kaputten, inkonsistenten Zustand hinterlassen (Geld belastet, aber nicht gutgeschrieben).

## transaction.atomic — Alles-oder-Nichts

```python
from django.db import transaction

# as a context manager
def transfer_money(from_account, to_account, amount):
    with transaction.atomic():           # everything inside is ONE transaction
        from_account.balance -= amount
        from_account.save()
        to_account.balance += amount
        to_account.save()
    # if ANY operation raises an exception, the WHOLE block is ROLLED BACK
    # → either both saves happen, or neither does (atomicity)
```

```python
# or as a decorator on a whole function/view
@transaction.atomic
def create_order(request):
    order = Order.objects.create(...)
    for item in items:
        OrderItem.objects.create(order=order, ...)
    # all-or-nothing: a failure anywhere rolls back the entire order creation
```

Innerhalb von `atomic()` rollback Django **jede Änderung** im Block zurück, wenn eine Operation eine Exception wirft — die Datenbank wird also nie halb-aktualisiert hinterlassen. Bei Erfolg werden alle Änderungen zusammen committed.

## Verschachtelte atomic-Blöcke (Savepoints)

```python
with transaction.atomic():               # outer transaction
    do_something()
    try:
        with transaction.atomic():       # inner = a SAVEPOINT
            risky_operation()
    except Exception:
        pass                              # inner rolls back to the savepoint; outer continues
```

Verschachtelte `atomic`-Blöcke verwenden Savepoints — der innere Block kann unabhängig zurückgerollt werden, ohne die gesamte äußere Transaction abzubrechen.

## Wichtige Details

```text
✓ Catch exceptions OUTSIDE the atomic block (catching inside can break rollback handling)
✓ select_for_update() locks rows within a transaction (prevent race conditions on updates)
    with transaction.atomic():
        account = Account.objects.select_for_update().get(pk=id)  # row locked until commit
✓ ATOMIC_REQUESTS setting wraps EVERY request in a transaction (per-database)
✓ Keep transactions SHORT — long transactions hold locks, hurting concurrency
```

## Warum es wichtig ist

Datenbanktransactionen sind essentiell für **Datenintegrität**, wann immer eine Operation mehrere zusammenhängende Datenbankänderungen beinhaltet, die als Einheit erfolgreich sein oder fehlschlagen müssen — und das Verständnis von `transaction.atomic` ist wichtiges Wissen für den Aufbau korrekter, zuverlässiger Anwendungen.

Das Kernproblem, das Transactionen lösen, ist **partieller Fehler**: Ohne Atomarität wird die Datenbank in einem inkonsistenten Zustand hinterlassen, wenn eine mehrstufige Operation fehlschlägt (ein Crash, eine Exception, eine Constraint-Verletzung) — das klassische Geldtransfer-Beispiel (von einem Konto belastet, aber nicht auf ein anderes gutgeschrieben) zeigt, wie dies Daten beschädigt und ernsthafte Folgen haben kann. `transaction.atomic` bietet die Garantie, dass Operationen **Alles-oder-Nichts** sind (rollt den gesamten Block bei jedem Fehler zurück), was für jede Operation über mehrere Writes hinweg erforderlich ist — eine Bestellung mit ihren Zeilenelementen erstellen, Gelder transferieren, verwandte Datensätze aktualisieren — um eine konsistente Datenbank zu erhalten.

Das Verständnis, wie man atomic-Blöcke verwendet (als Context Manager oder Decorator), verschachtelte Transactionen mit Savepoints, und die wichtigen Details — Exceptions *außerhalb* des Blocks abfangen, **`select_for_update()`** verwenden, um Zeilen zu sperren und Race Conditions bei gleichzeitigen Updates zu verhindern, und Transactionen kurz halten, um Locks zu vermeiden — ist praktisches Wissen für den Aufbau robuster Anwendungen.

Datenkonsistenz ist eine Grundanforderung zuverlässiger Systeme, und Transactionen sind der Mechanismus, der sie für mehrstufige Datenbankoperationen gewährleistet, was dieses Thema zu einem wichtigen macht, das Entwickler unterscheidet, die korrekten, integritätsbewahrenden Code schreiben, von denen, deren Anwendungen unter Fehlerbedingungen oder gleichzeitigem Zugriff stille Daten beschädigen können — ein häufig relevantes Problem in jeder Anwendung, die wichtige, zusammenhängende Datenänderungen verarbeitet.