Prambule Systmes de gestion de bases de donnes

Préambule 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 Vertigo NFP 107

Préambule 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[s 1]r[c 1]w[s 2]w[c 1]C peut-elle être engendrée par la procédure Réservation? • J’exécute la commande: DELETE * FROM Mes. Clients; 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? Vertigo NFP 107

Préambule Passons à la pratique… • Après la théorie, voyons ce que signifie le contrôle de concurrence en pratique ▫ On utilise My. SQL, avec le moteur de stockage Inno. DB ▫ 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 Vertigo NFP 107

Préambule 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é. Vertigo NFP 107

Préambule 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. Vertigo NFP 107

Préambule Niveaux d’isolation SQL • Définis par la norme SQL. 4 niveaux ▫ READ UNCOMMITED Possibilité de lire des données non validées (My. SQL) ▫ 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 (My. SQL/Inno. DB) ▫ SERIALIZABLE Isolation totale (tous les systèmes, pas par défaut) Vertigo NFP 107

Préambule 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. Vertigo NFP 107

Préambule 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. Vertigo NFP 107

Préambule 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? Vertigo NFP 107

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

Préambule 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… Vertigo NFP 107

Préambule 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 … Vertigo NFP 107

Préambule 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 Vertigo NFP 107

Préambule 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 My. SQL/Inno. DB. Vertigo NFP 107