Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Isolation de transaction : L’isolation est l’une des quatre propriétés ACID, el

Isolation de transaction : L’isolation est l’une des quatre propriétés ACID, elle permet d'isoler les opérations faites par une transaction de celles faite par d’autres transactions simultanément sur les mêmes tables. Exemple de problème qui peut avoir lieu quand deux transactions sont concurrentes : Soit la table vols : Vols Numéro de vol Nombre de places réservée V1 X V2 Y - On considère une transaction T1 qui consiste à annuler N réservations sur un vol V1 et à réserver N places sur un vol V2 - La transaction T2 réserve M places sur le vol V1. Donc le résultat attendu est X=X-N+M Ici nous montrons quelques problèmes qu’on peut rencontrer lors de l’exécution des 2 transaction au même moment sur les mêmes données. T1 T2 1- lire(X) 2- X : = X-N 3- 4- 5- écrire(X) 6- lire(Y) 7- 8- Y : = Y+N 9- écrire(Y) 1- 2- 3- lire(X) 4- X : = X+M 5- 6- 7- écrire(X)--> écrire(X: =X-N)est 8- perdu par T1 9- Dans cette exemple les deux transactions modifient le même enregistrement en parallèle, sans tenir compte l'une de l'autre (donc une sera écrasée et n'aura aucun effet). Puisque T2 est la dernière transaction à modifier X, la transaction T1 n’est pas prise en compte. Donc au lieu d’avoir X-N+M comme valeur final de X, on aura X+M comme valeur final. Ce genre de problème est appelé « perte d’opération » ou « mise à jour perdu ». Les solutions mises en place pour résoudre ce problème : Comme solution on peut utiliser un ordonnancement sériel, c’est-à-dire que les transactions ne s’exécutent pas en parallèle, donc aucune transaction ne peut gaspiller le travail de l’autre. Le problème qui se pose est le fait qu’il n’y a pas de parallélisme peut ralentir le travail. C’est pourquoi on utilise la notion de verrouillage qui permet d’avoir plusieurs transactions en parallèle tout en évitant les opérations conflictuels (comme T1 fait une écriture et T2 une lecture ou T1 et T2 font une écriture en même temps). Un verrou est un mécanisme utilisé pour contrôler l’accès à une même donnée par plusieurs utilisateurs. Lorsqu’il y a des transactions SQL ,les verrous sont nécessairement utilisés. On utilise alors les instructions COMMIT et ROLLBACK pour libérer les verrous après avoir validé/invalidé la suite d’opérations SQL.  On utilise l’instruction LOCK TABLES en SQL pour verrouiller une ou plusieurs tables ;  On utilise UNLOCK TABLES pour déverrouiller une ou plusieurs tables ;  On peut réaliser des verrous exclusifs (EXCLUSIVE), partagés (SHARE) que ce soit sur une table ou sur une ligne. Niveaux d’isolation : Read Uncommited : Les instructions peuvent lire les lignes qui ont été modifiées par d’autres transactions mais pas encore validées. Les valeurs des données peuvent être modifiées et les lignes peuvent apparaitre ou disparaitre avant la fin de la transaction. Read Commited : Les requêtes de lecture et de modification opèrent seulement sur les données validées avant le début de la requête, elles ne voient jamais les données non validées ou les modifications validées pendant l'exécution de la requête par des transactions exécutées en parallèle. Néanmoins, le SELECT peu voir les modifications validées par d’autres transactions donc deux commandes SELECT successives peuvent voir des données différentes. Repeatable Read : Repeatable Read ne voit que les données validées avant que la transaction ait démarré. Il ne voit jamais ni les données non validées, ni les données validées par des transactions concurrentes durant son exécution. Ce niveau est différent de Read Committed parce qu'une requête dans une transaction Repeatable Read voit un instantané au début de la transaction, c’est-à-dire que les modifications validées par d’autres transactions ne seront pas affichées. Donc les commandes SELECT successives voient toujours les mêmes données. Serializable: Ce niveau ressemble à l'exécution sérielle de transactions pour toutes les transactions validées, c’est-à-dire qu’elles sont exécutées les unes après les autres, plutôt que simultanément. Les instructions ne peuvent pas lire les données qui ont été modifiées mais pas encore validées par d’autres transactions. Aucune transaction ne peut modifier les données lues par la transaction en cours jusqu’à ce que celle-ci soit terminée. Références : http://www-inf.it-sudparis.eu/COURS/bd/?idr=42 https://www.base-de-donnees.com/verrou-sql/ https://docs.postgresql.fr/11/transaction-iso.html https://docs.microsoft.com/en-us/sql/t-sql/statements/set- transaction-isolation-level-transact-sql?view=sql-server-ver15 uploads/Finance/ isolation-de-transaction-bd.pdf