Symfony 8.2: un attributo non rende atomica un’operazione

Due richieste arrivano quasi insieme. Entrambe vedono l’ultimo posto disponibile, entrambe provano a venderlo. Oppure due operatori lanciano l’importazione dello stesso catalogo mentre il primo processo sta ancora aggiornando prezzi e disponibilità. Il problema non è che il server sia lento: due esecuzioni possono essere corrette, prese singolarmente, e produrre un risultato sbagliato quando si sovrappongono.

Il nuovo attributo #[Lock] annunciato da Symfony il 16 ottobre 2026 rende esplicito il coordinamento direttamente sui controller. È una buona evoluzione: riduce codice ripetitivo e rende visibile una decisione architetturale. Ma sarebbe un errore confondere la brevità della sintassi con la completezza della garanzia.

Una precisazione temporale conta: al momento dell’annuncio Symfony 8.2 è ancora in sviluppo, con rilascio previsto per novembre 2026. Non è quindi una funzione da presentare come già disponibile nella release stabile consigliata per ogni progetto.

Che cosa fa davvero #[Lock]

Prima, per proteggere un’operazione bisognava ottenere una LockFactory, scegliere una chiave, acquisire il lock, decidere come gestire la contesa e rilasciarlo. Il componente Lock continua a fare il lavoro sottostante; l’attributo porta quella politica nel ciclo di vita del controller. Il punto decisivo è la chiave: due richieste che usano la stessa chiave competono per la stessa risorsa; chiavi diverse possono procedere in parallelo.

L’esempio più semplice è #[Lock('catalog', methods: 'POST')]: si protegge l’importazione che modifica il catalogo, senza bloccare necessariamente la pagina GET che mostra il modulo. Per un evento con posti limitati si può costruire una chiave per risorsa, ad esempio ticket-sale-{conference}. Non è una decorazione: scegliere una chiave troppo generale riduce inutilmente il parallelismo; sceglierne una troppo specifica può lasciare aperta la corsa che si voleva evitare.

Quando il lock è già occupato, il comportamento predefinito è una risposta HTTP 409 Conflict. Con blocking: true la seconda richiesta aspetta invece di essere respinta. Symfony supporta anche lock condivisi di lettura con read: true, utili quando più lettori possono convivere ma una scrittura deve restare esclusiva. Tutto questo è descritto nella documentazione del componente Lock.

Il dettaglio che rompe la promessa: trenta secondi

Il TTL predefinito indicato nell’annuncio è di 30 secondi e il lock non viene rinnovato automaticamente. Se un’importazione ne impiega 45, la prima richiesta potrebbe essere ancora dentro la sezione critica quando il lock scade. A quel punto una seconda richiesta può acquisire la stessa chiave. Sulla carta abbiamo serializzato l’accesso; nei fatti abbiamo riaperto la concorrenza proprio mentre l’operazione era in corso.

Il TTL non è un semplice parametro da aumentare fino a far sparire gli errori. Troppo breve e perdi la protezione; troppo lungo e un processo terminato male può lasciare gli altri in attesa fino alla scadenza. Per i lavori lunghi serve un disegno esplicito: durata massima attesa, rinnovo controllato del lock, verifica che l’istanza sia ancora proprietaria e strategia di recupero se non lo è.

Symfony permette di ricevere nel controller il lock acquisito tramite un argomento LockInterface e di richiamarne refresh() quando necessario. È un potere utile, ma sposta nuovamente una responsabilità sul codice applicativo: decidere quando il rinnovo è sicuro e che cosa fare se fallisce. Un lock scaduto non può essere trattato come se fosse ancora valido soltanto perché la richiesta non è finita.

La concorrenza non si elimina scrivendo meno codice. Si governa definendo quale stato può cambiare, chi ha il diritto di cambiarlo e come si riconosce un tentativo già eseguito.

Un lock applicativo non sostituisce una transazione

Immaginiamo un checkout: il controller ottiene il lock, verifica che il prodotto sia disponibile, aggiorna il database e invia una richiesta a un servizio di pagamento. Il lock coordina le richieste che collaborano usando quella chiave e lo stesso sistema di storage. Non trasforma automaticamente una sequenza di operazioni in una transazione indivisibile. Se il pagamento va a buon fine e il processo cade prima di registrarlo, il problema rimane. Se un altro percorso modifica lo stock senza usare lo stesso lock, il problema rimane. Se il lock scade prima del commit, il problema può perfino peggiorare.

La documentazione PostgreSQL sui lock di riga chiarisce una differenza fondamentale: la concorrenza sui dati va controllata anche nel database, dentro transazioni e vincoli coerenti con le invarianti che si vogliono mantenere. Un SELECT ... FOR UPDATE, un vincolo univoco o un aggiornamento condizionale non sono alternative decorative a un mutex applicativo; operano a un livello diverso, spesso indispensabile.

Il lock sul controller può ridurre collisioni costose e rendere più leggibile la politica di accesso. L’integrità del dato, invece, deve sopravvivere anche a processi interrotti, timeout, retry, percorsi applicativi alternativi e aggiornamenti concorrenti. Per un sistema serio, la domanda non è “uso il lock oppure la transazione?” ma “quale garanzia deve fornire ciascun livello?”.

Idempotenza: la richiesta che torna dopo il timeout

C’è poi una situazione che nessun mutex risolve da solo: il client invia una richiesta, il server la esegue, ma la risposta si perde. Il client riprova. Il primo lock è già stato rilasciato e la seconda richiesta entra regolarmente. Se l’operazione non è idempotente, possiamo creare un secondo ordine o ripetere un addebito senza avere mai avuto due esecuzioni simultanee.

Per questo, nei flussi con effetti economici o irreversibili, serve una chiave di idempotenza associata all’operazione logica e un registro persistente dei suoi esiti. Non è una teoria astratta: la documentazione Stripe sui retry idempotenti mostra come un’API possa riconoscere una ripetizione e restituire il risultato già associato alla stessa chiave. Il lock gestisce il “contemporaneamente”; l’idempotenza gestisce il “di nuovo”. Sono due problemi diversi.

Quando un 409 arriva prima di un 403

Il comportamento più interessante, e forse più sottovalutato, non riguarda le prestazioni. Symfony specifica che, quando la chiave non dipende dagli argomenti del controller, il lock viene acquisito prima della loro risoluzione. Anche il controllo tramite #[IsGranted] può avvenire dopo il lock, indipendentemente dall’ordine visivo degli attributi.

Conseguenza: una richiesta non autorizzata verso una risorsa occupata può ricevere 409 Conflict invece di 403 Forbidden; se il lock è bloccante, può attendere prima di scoprire che l’accesso sarebbe stato negato. Non significa automaticamente una vulnerabilità sfruttabile, ma significa che la semantica delle risposte, il consumo di risorse e i tempi osservabili vanno esaminati nel proprio modello di minaccia. Il tema si collega a un’altra riflessione su Symfony 8.2 e le prove di autenticazione: la sequenza dei controlli conta quanto la loro presenza.

La soluzione non è promettere che spostare una riga di attributi risolva tutto. Occorre verificare quali controlli precedono davvero l’acquisizione, quali informazioni rivela una risposta diversa e se abbia senso consentire a un richiedente non autorizzato di attendere su una risorsa contesa.

Lo storage decide se il lock esiste per tutti

In un’applicazione distribuita, un lock locale al singolo processo o al singolo host può essere perfettamente funzionante e completamente inutile per coordinare due nodi diversi. Symfony mette a disposizione diversi store, con proprietà differenti su scadenza, blocco e condivisione. Non tutti supportano allo stesso modo i lock condivisi; non tutti hanno un TTL. Prima di scegliere Redis, filesystem, database o un altro backend bisogna chiedersi quali processi devono davvero vedere la stessa chiave e quale comportamento ci si aspetta in caso di guasto.

È la stessa distinzione che attraversa molti sistemi: avere più componenti che funzionano individualmente non garantisce che condividano una visione coerente dello stato. Ne ho discusso, da un’altra prospettiva, nell’articolo su SQL e il posto giusto in cui collocare un problema architetturale. La posizione della garanzia non è un dettaglio di implementazione.

Cinque domande prima di mettere #[Lock] in produzione

• Quale risorsa proteggo? La chiave identifica l’operazione condivisa, non semplicemente il nome del controller?
• Quanto può durare davvero? TTL, rinnovo e perdita di ownership sono gestiti nei casi lenti e nei guasti?
• Chi condivide lo store? Tutti i processi, worker e nodi che modificano quella risorsa osservano lo stesso lock?
• Che cosa protegge il dato? Transazioni, vincoli e aggiornamenti condizionali garantiscono l’invariante anche senza il mutex?
• Che cosa succede a un retry? Esiste una chiave di idempotenza e un esito persistente per non ripetere effetti già avvenuti?

Aggiungerei un sesto controllo, spesso lasciato ai test di integrazione quando ormai è tardi: la contesa produce un 409 comprensibile al client, una coda di attesa ragionevole o un timeout che peggiora l’esperienza? Un sistema affidabile non si limita a rifiutare la seconda richiesta: sa spiegare che cosa il chiamante può fare dopo.

Meno boilerplate, stessa responsabilità

#[Lock] è un miglioramento concreto della superficie di sviluppo prevista per Symfony 8.2. Sposta una politica tecnica vicino al punto in cui serve e rende meno facile dimenticare acquisizione e rilascio. Non è poco. Ma la concorrenza è una proprietà del sistema, non della riga di codice che la dichiara.

Il criterio con cui valutare questa novità è quindi semplice: l’attributo ci aiuta a esprimere il coordinamento; non ci assolve dal dimostrare la correttezza dell’operazione. Quando entrano in gioco denaro, disponibilità, importazioni o processi lunghi, servono ancora confini, dati coerenti e retry progettati. La sintassi si è accorciata. La responsabilità, fortunatamente, no.