Hvordan fungerer databasetransaktioner i Django?

Question

Accepted Answer

En **databasetransaktion** grupperer flere operationer, så de enten **alle lykkes eller alle mislykkes sammen** (atomaritet) — hvilket forhindrer delvise, inkonsistente opdateringer. Django stiller `transaction.atomic` til rådighed for at ombryde operationer i en transaktion, hvilket sikrer dataintegri­tet for flertrins-operationer.

## Det problem, transaktioner løser

```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!
```

Uden en transaktion, hvis den anden operation mislykkes, har den første allerede committed — hvilket efterlader databasen i en brudt, inkonsistent tilstand (penge debiteret men ikke krediteret).

## transaction.atomic — alt-eller-intet

```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
```

Indeni `atomic()`, hvis nogen operation rejser en undtagelse, **rollbacker** Django hver ændring i blokken — så databasen bliver aldrig halvt opdateret. Ved succes committes alle ændringer sammen.

## Indlejrede atomic-blokke (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
```

Indlejrede `atomic`-blokke bruger savepoints — den indre blok kan rollbacke uafhængigt uden at afbryde hele den ydre transaktion.

## Vigtige detaljer

```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
```

## Hvorfor det betyder noget

Databasetransaktioner er væsentlige for **dataintegri­tet**, når en operation involverer flere relaterede databaseændringer, der må lykkes eller mislykkes som en enhed — og at forstå `transaction.atomic` er vigtig viden for at bygge korrekte, pålidelige applikationer.

Kerneproblem, som transaktioner løser, er **delvis fiasko**: uden atomaritet, hvis en flertrins-operation mislykkes på midten (et nedbrud, en undtagelse, en constraint-violation), bliver databasen efterladt i en inkonsistent tilstand — det klassiske pengeoverførelseseksempel (debiteret fra én konto men ikke krediteret til anden) illustrerer, hvordan dette korrumperer data og kan have alvorlige konsekvenser. `transaction.atomic` giver garantien om, at operationer er **alt-eller-intet** (rollback af hele blokken ved nogen fiasko), hvilket er nødvendigt for enhver operation, der spænder over flere skrivninger — oprettelse af en ordre med dens lineposter, pengeoverførsel, opdatering af relaterede poster — for at bibeholde en konsistent database.

At forstå, hvordan man bruger atomic-blokke (som context manager eller decorator), indlejrede transaktioner med savepoints, og vigtige detaljer — at fange undtagelser *uden for* blokken, bruge **`select_for_update()`** til at låse rækker og forhindre race conditions i samtidige opdateringer, og holde transaktioner korte for at undgå at holde låse — er praktisk viden for at bygge robuste applikationer.

Datakonsistens er et grundlæggende krav til pålidelige systemer, og transaktioner er mekanismen, der sikrer det for flertrins-databaseoperationer, hvilket gør dette til et vigtigt emne, der skelner udviklere, der skriver korrekt, integri­tetsbevaret kode fra dem, hvis applikationer kan stille korrupte data under fejltilstande eller samtidigt adgang — en hyppigt relevant bekymring i enhver applikation, der håndterer vigtig, relaterede dataændringer.