Come funziona @Transactional, inclusi propagation e rollback?

Question

IT Interview Practice · Accepted Answer

`@Transactional` avvolge un metodo in una transazione di database: Spring ne apre una prima che il metodo venga eseguito e fa il commit quando termina normalmente — oppure esegue il **rollback** se solleva un'eccezione. Sotto il cofano è un **proxy AOP**, che è la fonte della maggior parte delle insidie.

## Uso di base

```java
@Service
public class TransferService {

@Transactional // commit on success, roll back on RuntimeException
    public void transfer(Long from, Long to, BigDecimal amount) {
        accounts.debit(from, amount);
        accounts.credit(to, amount); // if THIS throws, the debit is rolled back too
    }
}
```

## La regola di rollback predefinita (una trappola classica)

Per impostazione predefinita Spring esegue il rollback solo sulle eccezioni **unchecked** (`RuntimeException`) e su `Error` — **non** sulle eccezioni checked. Se sollevi un'eccezione checked, la transazione fa il *commit*. Sovrascrivilo esplicitamente:

```java
@Transactional(rollbackFor = Exception.class) // roll back on checked too
public void process() throws IOException { /* ... */ }
```

## Propagation

La propagation decide cosa succede quando un metodo transazionale ne chiama un altro:

- **REQUIRED** (predefinito): si unisce alla transazione del chiamante, o ne avvia una se non ne esiste alcuna.
- **REQUIRES_NEW**: sospende la transazione del chiamante ed esegue in una nuova transazione indipendente — utile per audit log che devono persistere anche se il lavoro esterno fa il rollback.

```java
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void writeAuditLog(String event) { /* commits independently */ }
```

## La trappola della self-invocation

Poiché `@Transactional` funziona tramite un proxy, chiamare un metodo `@Transactional` da un altro metodo *nella stessa classe* aggira il proxy — l'annotazione viene silenziosamente ignorata. Chiama attraverso bean diversi, o inietta te stesso.

## Perché è importante

Le transazioni sono dove risiede la correttezza dei dati, quindi gli intervistatori insistono molto qui. La regola di rollback sulle eccezioni checked e il bug della self-invocation sono le due domande che distinguono in modo affidabile chi ha *usato* `@Transactional` da chi lo *comprende*.

Uso di base

La regola di rollback predefinita (una trappola classica)

Propagation

La trappola della self-invocation

Perché è importante

Domande correlate