“Bad Coding/Designing Practices”: Fare sempre Commit/Rollback delle transazioni all’interno di Stored Procedure

Bad Coding/Designing Practices, Ingegneria del Software 0 13

Subject
Gestione delle transazioni

Bad Practice
Fare sempre Commit/Rollback delle transazioni all’interno di Stored Procedure

Explanation
Inserire sempre e comunque il “commit” o “rollback” all’interno di una “Stored Procedure” sul DataBase o anche fare “commit/rollback parziale”, ad esempio a fronte di una Exception. Questa pratica spesso non è corretta, soprattutto in presenza di architetture software “multi-tier”, dove il DB potrebbe “coprire” lo strato di persistenza e una parte di business logic (con un certo livello di astrazione).

Problem
Uno dei problemi che si potrebbe verificare è l’impossibilità (o l’estrema difficoltà per via delle innumerevoli modifiche da effettuare sul codice) di “aggregare” le funzioni “business” esposte dalle “Stored Procedure”  su uno strato applicativo più alto, o anche di gestire, sempre sullo strato applicativo più alto, delle transazioni distribuite con altre componenti.
Un altro problema (in caso di “commit/rollback parziale”) è l’impossibilità da parte del Client della procedura di capire gli effetti della procedura stessa (chiamando la procedura P, se capita quello ottengo questo, se capita quell’altro ottengo quest’altro…)

Fix
Non fare mai commit o rollback della transazione all’interno di una “Stored Procedure” (a meno di situazioni che lo richiedano espressamente), ma farlo sempre sullo strato client della stessa (ad esempio sullo strato “middleware”).

Note

Scope
Linguaggi PL/SQL, T-SQL e altri linguaggi per scrivere “Stored Procedure”

About the author / 

Salvatore Di Loro

Related Posts

Leave a reply

Your email address will not be published. Required fields are marked *

Instagram

Flickr