Jak działają transakcje bazy danych w Django?

Question

Accepted Answer

**Transakcja bazy danych** grupuje wiele operacji tak, aby **wszystkie powiodły się lub wszystkie się nie powiodły razem** (atomowość) — zapobiegając częściowym, niespójnym aktualizacjom. Django udostępnia `transaction.atomic` do zawinięcia operacji w transakcję, zapewniając integralność danych dla operacji wieloetapowych.

## Problem, który rozwiązują transakcje

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

Bez transakcji, jeśli druga operacja się nie powiedzie, pierwsza już się zacommitowała — pozostawiając bazę danych w złanym, niespójnym stanie (pieniądze obciążone ale nie przelane).

## transaction.atomic — wszystko-albo-nic

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

Wewnątrz `atomic()`, jeśli jakakolwiek operacja zgłosi wyjątek, Django **cofa** każdą zmianę w bloku — więc baza danych nigdy nie zostaje półprzywrócona. Po sukcesie wszystkie zmiany commitują się razem.

## Zagnieżdżone bloki atomic (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
```

Zagnieżdżone bloki `atomic` używają savepoints — wewnętrzny blok może się cofnąć niezależnie bez przerwania całej zewnętrznej transakcji.

## Ważne szczegóły

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

## Dlaczego to ważne

Transakcje bazy danych są niezbędne do **integralności danych** zawsze, gdy operacja obejmuje wiele powiązanych zmian w bazie danych, które muszą się powiększyć lub nie powiedzieć jako jednostka — i zrozumienie `transaction.atomic` jest ważną wiedzą do budowania poprawnych, niezawodnych aplikacji.

Problematycznym problemem, który rozwiązują transakcje, jest **częściowa awaria**: bez atomowości, jeśli operacja wieloetapowa nie powiedzie się w połowie (awaria, wyjątek, naruszenie ograniczenia), baza danych pozostaje w niespójnym stanie — klasyczny przykład przelewu pieniędzy (obciążono z jednego konta, ale nie przelano na inne) ilustruje, jak to korumpuje dane i może mieć poważne konsekwencje. `transaction.atomic` zapewnia gwarancję, że operacje są **wszystkim-lub-niczym** (cofając cały blok w przypadku jakiegokolwiek błędu), co jest konieczne dla dowolnej operacji obejmującej wiele zapisów — tworzenie zamówienia z jego pozycjami, transfer funduszy, aktualizowanie powiązanych rekordów — aby utrzymać spójną bazę danych.

Zrozumienie, jak używać bloków atomic (jako menedżera kontekstu lub dekoratora), zagnieżdżonych transakcji z savepoints i ważnych szczegółów — przechwytywanie wyjątków *poza* blokiem, używanie **`select_for_update()`** do blokowania wierszy i zapobiegania warunkami wyścigu w równoczesnych aktualizacjach, i trzymanie transakcji krótkich, aby uniknąć trzymania blokad — to praktyczna wiedza do budowania solidnych aplikacji.

Spójność danych jest fundamentalnym wymaganiem niezawodnych systemów, a transakcje są mechanizmem, który to zapewnia dla operacji bazy danych obejmujących wiele etapów, czyniąc to ważnym tematem, który rozróżnia deweloperów, którzy piszą poprawny, integralność-zachowujący kod od tych, których aplikacje mogą dyskretnie korumpować dane w warunkach niepowodzenia lub równoczesnego dostępu — częsty problem w każdej aplikacji obsługującej ważne, powiązane zmiany danych.