Systèmes de gestion de bases de données NFP 107 Introduction à la concurrence d’accès Second fragment Philippe Rigaux philippe.rigaux@cnam.fr http://idf.pleiad.net/index.php

Réponses… J’effectue un commit, puis je m’aperçois d’une erreur: est-il encore temps de faire un rollback? La transaction r[s1]r[c1]w[s2]w[c1]C peut-elle être engendrée par la procédure Réservation? J’exécute la commande: DELETE * FROM MesClients; WHERE id=1; Réponse: 100 000 lignes détruites. Pourquoi et que faire? Exécution de Réservation: je lis un spectacle: il reste 10 places libres; je veux en réserver 5: on me répond qu’une autre transaction a tout pris. Est-ce possible dans un système transactionnel?

Passons à la pratique… Après la théorie, voyons ce que signifie le contrôle de concurrence en pratique On utilise MySQL, avec le moteur de stockage InnoDB On crée les tables Client et Spectacle On choisit un niveau d’isolation READ COMMITTED (même qu’ORACLE) On lance deux sessions, en désactivant le mode autocommit Et on regarde le comportement -> illustration avec quelques commandes Toutes les commandes sont dans cmdtrans.sql

Expérience 1: l’isolation en pratique Même scénario que dans le polycopié On effectue deux réservations dans deux sessions différentes. La première finit par un commit La seconde par un rollback Même déroulé que dans le polycopié.

Les niveaux d’isolation Choisir le niveau d’isolation est un compromis entre Aucune isolation: fluidité totale; anomalies possibles (et fréquentes) Niveau d’isolation totale: Aucune anomalie Fluidité faible; au pire une transaction peut être rejetée (deadlock) Très important: les systèmes choisissent un mode par défaut qui n’est pas l’isolation totale.

Niveaux d’isolation SQL Définis par la norme SQL. 4 niveaux READ UNCOMMITED Possibilité de lire des données non validées (MySQL) READ COMMITTED On ne peut lire que des données validées, elles peuvent changer en cours de transaction (ORACLE) REPEATABLE READ On ne lit que des données validées avant le début de la transaction, et une lecture renvoie toujours la même valeur (MySQL/InnoDB) SERIALIZABLE Isolation totale (tous les systèmes, pas par défaut)

Expérience 2: problèmes en cas d’isolation insuffisante. On se met en mode READ UNCOMMITTED On joue l’exemple des mises à jour perdues Les deux transactions lisent d’abord Les deux transactions écrivent ensuite Une des mises à jour est perdue Typique du problème le plus grave et le plus fréquent: on lit une donnée pour la modifier ensuite.

Expérience 3: tuples fantômes Toujours en mode READ UNCOMMITTED Une des sessions effectue un contrôle de cohérence: On lit les clients On lit le spectacle On vérifie qu’il y a autant de places payées (par les clients) que de places réservées (spectacle) La seconde session effectue une réservation.

Expérience 4: lectures sales = lecture d’une donnée modifiée par une autre transaction, mais pas encore validée. Toujours en mode READ UNCOMMITTED La première session commence une réservation La seconde début et lit une donnée non validée La première effectue un rollback. Que doit faire la seconde?

Retour sur les niveaux d’isolation Lectures sales Lectures non répétables Tuples fantômes READ UNCOMMITTED Possible READ COMMITTED Impossible REPEATABLE READ SERIALIZABLE Essentiel: le cas des mises à jour perdues et possibles dans tous les modes, Sauf SERIALIZABLE

Expérience 5: mode SERIALIZABLE On reprend l’exemple des mises à jour perdues On se met en mode SERIALIZABLE Et on constate le comportement du système…

Une possibilité: FOR UPDATE Permet de gérer le cas-type des mises à jour perdues On lit une donnée pour la modifier ensuite Une autre transaction fait la même chose Tout le monde se retrouve bloqué La clause FOR UPDATE permet de « réserver » un ligne au moment de la lecture. Donc pas d’interblocage Séduisant, mais difficile à appliquer …

Conclusion forte Les systèmes de garantissent pas, par défaut, la sérialisabilité Des anomalies peuvent survenir Il est extrêmement difficile de comprendre des anomalies qui surviennent très rarement Noter que les programmes peuvent être corrects Il est donc impératif de se mettre en mode SERIALIZABLE pour les procédures transactionnelles: celles qui passent d’un état cohérent de la base à une autre Il faut accepter comme un moindre mal le rejet parfois, de certaines transactions

Pour réfléchir Reprendre les expériences Pour chacune, se mettre dans un mode donné Essayer de prévoir le résultat Quand une session va être bloquée Quand on va aboutir à une anomalie Faire l’expérience avec MySQL/InnoDB.