Immaginate di trasferire 200.000 euro da un conto bancario a un altro. Si preleva l’importo dal conto di origine e poi lo si deposita sul conto di destinazione. Fin qui tutto normale e in un mondo perfetto l’operazione andrà a buon fine. Purtroppo, nel mondo reale le cose possono andare male. Succede qualcosa e il denaro va perso. È una situazione molto negativa.
Ebbene, le transazioni sono qui per garantire che questo non accada con le vostre applicazioni! In questo post esploriamo in dettaglio l’uso e l’importanza delle transazioni, oltre a diversi scenari che mostrano come possono salvare la vostra attività.
Cosa sono le transazioni?
Secondo la documentazione:
Le transazioni sono una serie di modifiche di dati correlate apportate a un database nell’ambito di un processo. Una transazione non viene salvata in modo permanente su un database finché non viene convalidata. Se una transazione non viene completata, perché annullata o a causa di un evento esterno, le modifiche non vengono salvate.
È importante notare che:
Quando si utilizzano transazioni annidate, il risultato di ciascuna transazione secondaria dipende dalla convalida o dall’annullamento della transazione di livello superiore. Se la transazione di livello superiore viene convalidata, i risultati delle sotto-transazioni vengono confermati (convalida o annullamento). Se invece la transazione di livello superiore viene annullata, tutte le sotto-transazioni vengono annullate, indipendentemente dai rispettivi risultati.
Per maggiori informazioni sulle transazioni, consultare la documentazione.
Utilizzo delle transazioni
È difficile immaginare applicazioni aziendali che non utilizzino le transazioni, eppure di tanto in tanto le ho viste! Quando si discute di questa mancanza di transazioni con gli sviluppatori dell’applicazione, ho sentito frasi come “oh, finora ha funzionato”, o anche “siamo sempre stati fortunati”. A mio parere, la fortuna non dovrebbe essere un concetto di progettazione per le applicazioni aziendali.
Un classico esempio di utilizzo delle transazioni è la contabilità. I rendiconti finanziari registrano due categorie: attività e passività. Entrambe devono essere calcolate e salvate (completamente, mai parzialmente), oppure non devono essere toccate affatto.
Un altro esempio è il sistema di spedizione, dove la creazione di un ordine diminuisce l’inventario del magazzino. Piuttosto che affidarci alla fortuna, dobbiamo assicurarci che sia l’ordine che i record dell’inventario vengano creati o modificati insieme. In ogni caso, entrambe le operazioni vengono completate o annullate.
Si può pensare a una transazione come a una sorta di grande parentesi:
- La si apre (START TRANSACTION comando),
- eseguire operazioni nel database (creare/modificare/cancellare record – da una o più tabelle),
- poi la si chiude convalidando (VALIDATE TRANSACTION comando) o annullando (CANCEL TRANSACTION comando) TUTTE le operazioni.
Oltre alle operazioni di basso livello sul database, un altro buon caso di utilizzo delle transazioni è l’interfaccia utente. Immaginate un modulo per l’inserimento di una fattura, che utilizzi una casella di riepilogo (o un modulo secondario) con articoli di prodotti (memorizzati in un’altra tabella) … o clienti e contatti … o contatti e numeri di telefono. L’elenco continua e continua ….
L’utente vuole modificare una fattura. Potrebbe modificare una o più voci e poi decidere di fare clic sul pulsante di annullamento, assumendo che tutte le modifiche alle voci della fattura siano annullate (non salvate). Si potrebbe gestire questa situazione con array complessi o semplicemente utilizzando una transazione.
Si spera che si utilizzino già le transazioni.
usare le transazioni annidate
Scenario uno: un’applicazione di contatto
Supponiamo di avere una struttura semplice con due tabelle: clienti e contatti. Si dispone di un modulo di input per i clienti che include una casella di riepilogo dei record dei contatti. Facendo doppio clic su un record, si apre un modulo di inserimento del contatto con ulteriori dettagli.
Ecco cosa potrebbe accadere:
- Un utente finale apre un record cliente e modifica il nome della via.
- Quindi apre il contatto ‘A’, modifica la data di nascita e chiude il modulo di contatto facendo clic sul pulsante OK.
- Poi apre il contatto ‘B’, modifica qualcosa e decide di annullare le modifiche.
- Tornando al modulo cliente, l’utente finale fa clic su un pulsante OK per completare le proprie attività.
L’utente si aspetta che la sua modifica del contatto ‘A’ venga salvata, mentre quella del contatto ‘B’ no. Naturalmente, anche le modifiche al record del cliente devono essere salvate.
Con le transazioni annidate, questo è facilmente gestibile. Basta utilizzare una transazione nel modulo cliente e un’altra transazione nel modulo contatto. Nessun problema!
Scenario due: elaborazione automatica in batch
Uno scenario completamente diverso, ma con lo stesso concetto, è l’elaborazione automatica di batch (calcoli, importazioni, ecc.):
- Nel bel mezzo di un lavoro batch complesso, è necessario interrompere il processo per qualche motivo(ad esempio, dati errati o richiesta di annullamento da parte dell’utente).
Con una transazione a livello singolo, è possibile solo annullare tutte le operazioni o fermarsi nel mezzo, con il risultato di una situazione poco chiara. Si potrebbe pensare: “Non mi fermerei a metà, finirei l’operazione prima di fermarmi”. È un’ottima idea, ma come gestireste interruzioni di corrente, crash, guasti hardware e altri errori imprevisti?
Poiché non è possibile… e contare sulla fortuna non è affidabile… il sistema deve essere progettato per garantire dati affidabili.
tenere presente che…
Le transazioni consentono di controllare questo tipo di situazioni. Utilizzate transazioni individuali per ogni operazione (importazione di dati, esecuzione di calcoli, ecc.) annidate all’interno di una transazione di livello superiore (per consentire l’annullamento o la convalida di tutte le operazioni).
Se una transazione non viene completata per qualsiasi motivo (crash, interruzione di corrente, ecc.), non c’è da temere! Ogni operazione già eseguita viene annullata perché nulla è stato ancora convalidato dalla transazione di livello superiore.