Kuinka tietokantatapahtumien (database transactions) toiminta Django:ssa?

Question

Accepted Answer

**Tietokantatapahtuma** ryhmittelee useita operaatioita niin, että ne joko **kaikki onnistuvat tai kaikki epäonnistuvat yhdessä** (atomisuus) — estäen osittaiset, epäyhteneväiset päivitykset. Django tarjoaa `transaction.atomic`-funktiota operaatioiden käärimiseksi tapahtumaan, varmistamalla tietojen eheyden monivaiheisille operaatioille.

## Ongelma, jonka tapahtumat ratkaisevat

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

Ilman tapahtumaa, jos toinen operaatio epäonnistuu, ensimmäinen on jo sitoutunut — jättäen tietokannan rikkinäiseen, epäyhtenäiseen tilaan (raha veloitettu mutta ei hyvitetty).

## transaction.atomic — kaikki tai ei mitään

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

`atomic()`-lohkon sisällä, jos jokin operaatio nosta poikkeuksen, Django **palauttaa** jokaisen muutoksen lohkossa — niin että tietokanta ei koskaan jää puoliksi päivitettyyn. Onnistumisen yhteydessä kaikki muutokset sitoutuvat yhdessä.

## Sisäkkäiset atomic-lohkot (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
```

Sisäkkäiset `atomic`-lohkot käyttävät savepoint-pisteitä — sisempi lohko voi palautua itsenäisesti ilman koko ulomman tapahtuman keskeyttämistä.

## Tärkeät yksityiskohdat

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

## Miksi tämä on tärkeää

Tietokantatapahtumien käyttö on oleellista **tietojen eheydelle** silloin, kun operaatio sisältää useita toisiinsa liittyviä tietokantamuutoksia, jotka on joko onnistuttava tai epäonnistuttava yhtenä kokonaisuutena — ja `transaction.atomic`-funktion ymmärtäminen on tärkeä tieto oikeiden ja luotettavien sovellusten rakentamista varten.

Ydinongelmaa, jonka tapahtumat ratkaisevat, kutsutaan **osittaiseksi epäonnistumiseksi**: ilman atomisuutta, jos monivaiheinen operaatio epäonnistuu kesken (kaatuminen, poikkeus, rajoitusrikkomus), tietokanta jää epäyhtenäiseen tilaan — klassinen rahansiirtotapaus (veloitus yhdeltä tililtä mutta ei hyvitys toiselle) osoittaa, kuinka tämä korruptoi tietoja ja voi aiheuttaa vakavia seurauksia. `transaction.atomic` antaa takuun, että operaatiot ovat **kaikki tai ei mitään** (koko lohkon palautus missä tahansa epäonnistumisessa), mikä on välttämätöntä kaikille useiden kirjoituksien kattavalle operaatioille — tilauksen luominen sen rivikohteilla, varojen siirto, liittyvien tietueiden päivitys — tietokantayhtenäisyyden ylläpitämiseksi.

Atomisen lohkon käyttö (kontekstipäällikkönä tai dekoraattorina), sisäkkäiset tapahtumat savepoint-pisteillä ja tärkeät yksityiskohdat — poikkeuksien sieppaus *lohkon ulkopuolella*, **`select_for_update()`**-käyttö rivien lukitsemiseksi ja kilpailutilanteen estämiseksi samanaikaisissa päivityksissä sekä tapahtumien pitäminen lyhyinä lukkojen hallussapidon välttämiseksi — on käytännöllistä tietoa vankkoja sovelluksia varten.

Tiedon yhtenäisyys on luotettavien järjestelmien perusvaatimus, ja tapahtumat ovat mekanismi, joka varmistaa sen monivaiheisille tietokantatoiminnoille, mikä tekee tästä tärkeän aiheen, joka erottaa kehittäjät, jotka kirjoittavat oikeitä, eheyttä säilyttäviä koodia, niistä, joiden sovellukset voivat hiljaa vahingoittaa tietoja vikaantumistilanteissa tai samanaikaisessa käytössä — usein relevantti huolenaihe missä tahansa sovelluksessa, joka käsittelee tärkeitä, toisiinsa liittyviä tietojen muutoksia.