Come funzionano le transazioni di database in Django?

Question

Accepted Answer

Una **transazione di database** raggruppa più operazioni affinché **abbiano tutti successo o falliscano insieme** (atomicità) — prevenendo aggiornamenti parziali e incoerenti. Django fornisce `transaction.atomic` per avvolgere operazioni in una transazione, assicurando l'integrità dei dati per operazioni multi-step.

## Il problema che le transazioni risolvono

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

Senza una transazione, se la seconda operazione fallisce, la prima si è già committed — lasciando il database in uno stato rotto e incoerente (denaro addebitato ma non accreditato).

## transaction.atomic — tutto-o-niente

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

Dentro `atomic()`, se un'operazione qualsiasi genera un'eccezione, Django **esegue il rollback** di ogni modifica nel blocco — quindi il database non viene mai lasciato a metà aggiornamento. Al successo, tutte le modifiche vengono committate insieme.

## Blocchi atomic annidati (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
```

I blocchi `atomic` annidati utilizzano savepoint — il blocco interno può eseguire il rollback indipendentemente senza interrompere l'intera transazione esterna.

## Dettagli importanti

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

## Perché è importante

Le transazioni di database sono essenziali per l'**integrità dei dati** ogni volta che un'operazione coinvolge più modifiche di database correlate che devono avere successo o fallire come unità — e comprendere `transaction.atomic` è una conoscenza importante per costruire applicazioni corrette e affidabili.

Il problema fondamentale che le transazioni risolvono è il **fallimento parziale**: senza atomicità, se un'operazione multi-step fallisce a metà (un crash, un'eccezione, una violazione di vincolo), il database rimane in uno stato incoerente — l'esempio classico del trasferimento di denaro (addebitato da un conto ma non accreditato a un altro) illustra come questo corrompe i dati e può avere conseguenze serie. `transaction.atomic` fornisce la garanzia che le operazioni siano **tutto-o-niente** (eseguendo il rollback dell'intero blocco al primo fallimento), necessaria per qualsiasi operazione che attraversa più scritture — creando un ordine con i suoi articoli, trasferendo fondi, aggiornando record correlati — per mantenere un database coerente.

Comprendere come utilizzare blocchi atomic (come context manager o decoratore), transazioni nidificate con savepoint, e i dettagli importanti — catturare eccezioni *fuori* dal blocco, utilizzare **`select_for_update()`** per bloccare righe e prevenire condizioni di race in aggiornamenti concorrenti, e mantenere le transazioni brevi per evitare di tenere bloccati i lock — è conoscenza pratica per costruire applicazioni robuste.

La coerenza dei dati è un requisito fondamentale di sistemi affidabili, e le transazioni sono il meccanismo che la assicura per operazioni di database multi-step, rendendo questo un argomento importante che distingue gli sviluppatori che scrivono codice corretto e che preserva l'integrità da quelli le cui applicazioni possono corrompere silenziosamente i dati in condizioni di fallimento o accesso concorrente — una preoccupazione frequentemente rilevante in qualsiasi applicazione che gestisce importanti modifiche di dati correlati.