Qui plus est, le SELECT a été exécuté (vous devrez peut-être appuyer sur Entrée pour que ce soit envoyé au serveur) et les
modifications ayant été faites par la session 1 ont été prises en compte : commentaires vaut 'Agressif' et pere_id vaut 73 !
id nom commentaires pere_id mere_id
69 Baba NULL
NULL NULL
70 Bibo
Agressif
73
72
72 Momy NULL
NULL NULL
73 Popi
NULL
NULL NULL
75 Mimi NULL
NULL NULL
Il est possible que votre seconde session indique ceci :
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction . Cela
signifie que la session est restée bloquée trop longtemps et que par conséquent la transaction a été automatiquement
fermée (avec un rollback des requêtes effectuées). Dans ce cas, recommencez l'opération.
Il n'y a plus qu'à commiter les changements faits par la deuxième session, et c'est terminé ! Si vous ne commitez pas,
commentaires restera NULL. Par contre, pere_id vaudra toujours 73 puisque ce changement-là a été commité par la première
session.
Conclusion
La deuxième session n'a pas interagi avec les changements faits par la première session, chaque transaction est bien isolée.
Et la première session qui bloque la seconde, ce n'est pas une interaction ça ?
Pas dans le cadre des critères ACID. Oui, la première session provoque un retard dans l'exécution des requêtes de la deuxième
session, mais les critères de fiabilité que nous examinons ici concernent les données impactées par les transactions, et non le
déroulement de celles-ci (qui importe peu finalement).
Ce blocage a pour effet d'empêcher la deuxième session d'écraser un changement fait par la première. Donc, ce blocage a bien
pour effet l'isolation des transactions.
Verrous
Le blocage de la deuxième session vient en fait de ce que la première session, en faisant sa requête UPDATE, a automatiquement
posé un verrou sur la ligne contenant Bobi le rat, empêchant toute modification tant que la transaction était en cours. Les
verrous faisant l'objet du prochain chapitre, je n'en dis pas plus pour l'instant.
Utilité
Je vous l'accorde, vous n'allez pas vous amuser tous les jours à ouvrir deux sessions MySQL. Par contre, pour une application
pouvant être utilisée par plusieurs personnes en même temps (qui toutes travaillent sur la même base de données), il est impératif
que ce critère soit respecté.
Prenons l'exemple simple d'un jeu par navigateur : de nombreux joueurs peuvent être connectés en même temps, et effectuer des
opérations différentes. Si les transactions ne sont pas isolées, une partie des actions des joueurs risquerait de se voir annulées.
On isole donc les transactions grâce aux verrous (qui sont ici automatiquement posés mais ce n'est pas toujours le cas).
D pour Durabilité
Une fois la transaction terminée, les données résultant de cette transaction doivent être stockées de manière durable, et pouvoir
être récupérées, en cas de crash du serveur par exemple.
Nos transactions modifient-elles les données de manière durable ?
Partie 5 : Sécuriser et automatiser ses actions
231/414
www.openclassrooms.com
modifications ayant été faites par la session 1 ont été prises en compte : commentaires vaut 'Agressif' et pere_id vaut 73 !
id nom commentaires pere_id mere_id
69 Baba NULL
NULL NULL
70 Bibo
Agressif
73
72
72 Momy NULL
NULL NULL
73 Popi
NULL
NULL NULL
75 Mimi NULL
NULL NULL
Il est possible que votre seconde session indique ceci :
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction . Cela
signifie que la session est restée bloquée trop longtemps et que par conséquent la transaction a été automatiquement
fermée (avec un rollback des requêtes effectuées). Dans ce cas, recommencez l'opération.
Il n'y a plus qu'à commiter les changements faits par la deuxième session, et c'est terminé ! Si vous ne commitez pas,
commentaires restera NULL. Par contre, pere_id vaudra toujours 73 puisque ce changement-là a été commité par la première
session.
Conclusion
La deuxième session n'a pas interagi avec les changements faits par la première session, chaque transaction est bien isolée.
Et la première session qui bloque la seconde, ce n'est pas une interaction ça ?
Pas dans le cadre des critères ACID. Oui, la première session provoque un retard dans l'exécution des requêtes de la deuxième
session, mais les critères de fiabilité que nous examinons ici concernent les données impactées par les transactions, et non le
déroulement de celles-ci (qui importe peu finalement).
Ce blocage a pour effet d'empêcher la deuxième session d'écraser un changement fait par la première. Donc, ce blocage a bien
pour effet l'isolation des transactions.
Verrous
Le blocage de la deuxième session vient en fait de ce que la première session, en faisant sa requête UPDATE, a automatiquement
posé un verrou sur la ligne contenant Bobi le rat, empêchant toute modification tant que la transaction était en cours. Les
verrous faisant l'objet du prochain chapitre, je n'en dis pas plus pour l'instant.
Utilité
Je vous l'accorde, vous n'allez pas vous amuser tous les jours à ouvrir deux sessions MySQL. Par contre, pour une application
pouvant être utilisée par plusieurs personnes en même temps (qui toutes travaillent sur la même base de données), il est impératif
que ce critère soit respecté.
Prenons l'exemple simple d'un jeu par navigateur : de nombreux joueurs peuvent être connectés en même temps, et effectuer des
opérations différentes. Si les transactions ne sont pas isolées, une partie des actions des joueurs risquerait de se voir annulées.
On isole donc les transactions grâce aux verrous (qui sont ici automatiquement posés mais ce n'est pas toujours le cas).
D pour Durabilité
Une fois la transaction terminée, les données résultant de cette transaction doivent être stockées de manière durable, et pouvoir
être récupérées, en cas de crash du serveur par exemple.
Nos transactions modifient-elles les données de manière durable ?
Partie 5 : Sécuriser et automatiser ses actions
231/414
www.openclassrooms.com