idf.pleiad/index.php

1. Systèmes de gestion de bases de donnéesNFP 107Introduction à la concurrence d’accèsPhilippe Rigauxphilippe.rigaux@cnam.fr http://idf.pleiad.net/index.php

2. 1. Généralités

3. Objectifs de ce cours • Comprendre les mécanismes d’accès concurrents à une base de données • Connaître les risques liés à une gestion laxiste de la concurrence • Connaître aussi les inconvénients d’une gestion trop stricte • S’initier au concept de transaction, et interpréter dans ce contexte le comportement d’un SGBD transactionnel • Comprendre les modes de gestion de la concurrence offerts au niveau « logique »

4. Pour accompagner ce cours • Le polycopié (Introduction à la concurrence d’accès, Philippe Rigaux, Cnam) • Dispo à http://sys.bdpedia.fr en HTML • (PDF) http://www.bdpedia.fr/systemes-relationnels • Disposer d’un SGBD comme PostgreSQL ou MySQL pour effectuer quelques manipulations chez vous • Et bien entendu, faire les exercices du polycopié et autres

5. De quoi s’agit-il? • Deux hypothèses à reconsidérer • Un programme SQL s’exécute indépendamment des autres (« en isolation ») • -> de grandes bases de données peuvent gérer des centaines, voire des milliers d’accès concurrents • Un programme s’exécute sans erreur et intégralement • Raisons innombrables: plantage, pb réseau, pb du serveur, panne électrique, etc. • L’interruption peut laisser la base dans un état incohérent

6. SGBD et concurrence d’accès • Les SGBD assurent le contrôle de la concurrence (CC) • Les programmes concurrents sont contrôlés et surveillés • Certaines séquences d’opérations sont interdites, • A l’extrême, le CC assure que l’hypothèse 1 est vérifiée: les programmes s’exécutent en isolation • Un composant complémentaire est la reprise sur panne • CC et reprise sur panne sont liées par la notion de transaction.

7. Ce que nous devons savoir • Sans même comprendre les techniques utilisées (objet du prochain cours), il faut • Maîtriser la notion, centrale, de transaction • La spécification d’une transaction nous revient • Réaliser l’impact du CC sur les autres utilisateurs • Une transaction mal conçue peut faire perdre inutilement beaucoup de temps • Choisir un niveau d’isolation approprié • Difficile, mais potentiellement extrêmement important

8. 2. Notions de base

9. Transaction • Définition: une transaction est une séquence d’opérations de lecture ou d’écriture, se terminant par commit ou rollback • Le commit est une instruction qui valide toutes les mises à jour • Le rollback est une instruction qui annule toutes les mises à jour. • Les opérations d’une transaction sont solidaires: elles sont toutes validées, ou pas du tout.

10. Quelques précisions • On parle de transaction plutôt que de programme : plus précis • Une transaction s’exécute dans le cadre d’un processus client connecté au serveur SGBD. • On peut effectuer une ou plusieurs transactions dans un même processus: elles sont sérielles. • En revanche, deux processus distincts engendrent des transactions concurrentes.

11. Notre exemple de base • Notre base de données: • Des clients qui réservent des places pour des spectacles • Client (id_client, nb_places_réservées) • Des spectacles qui proposent des places à des clients. • Spectacle (id_spectacle, nb_places_offertes, nb_places_prises) • NB: cette base est cohérente si le nombre de places prises est égal à la somme des places réservées

12. Notre procédure Réservation • Ecrite en PL/SQL • mais équivalente, du point de vue transactionnel, à la même fonction écrite en n’importe quel autre langage. • Effectue des lectures et des mises à jour • Et notamment des mises à jour des données lues précédemment • Représentative des procédures qui posent le plus de problème • (ici: explication de la procédure à partir du code)

13. Architecture • La procédure précédente engendre des transactions Les deux espaces communiquent par message. Ils ne partagent rien. Processus Client (exécute Réservation) Processus Server (reçoit, exécute des requêtes) Le serveur envoie des données Le client envoie des requêtes Le serveur accède à la base et effectue ses propres calculs Invisible pour tous les clients Le Client gère - des données - des calculs Invisibles pour le serveur (ou les autres clients)

14. Représentation des transactions • Pour comprendre les mécanismes de concurrence, on va se limiter à l’essentiel • Les requêtes transmises par chaque processus (T1, T2, … Tn) au serveur • L’ordre dans lequel ces requêtes sont reçues • On va les représenter (modéliser) très simplement de la manière suivante: • ri[x]: Ti demande la lecture (read) de la donnée x. • wi[x]: Ti demande la mise à jour (write) de la donnée x. • Ci et Rireprésentent le commit et le rollback.

15. Qu’est-ce qu’une « donnée » • C’est l’unité d’information affectée par la requête. Cela peut être: • Toute la base • Toute une table • Une ligne dans une table • Une cellule (valeur) dans une ligne. • En théorie on peut tout considérer. En pratique: • Dans les SGBD relationnels, l’unité transactionnelle est la ligne dans une table

16. Exemples de transactions • En s’exécutant, la procédure Réservation engendre des transactions • r[s1]r[c1]w[s1]w[c1]C: on lit le spectacle s1, le client c1, puis on les met à jour tous les deux • r[s1]r[c2]w[s1]w[c2]C: un autre client réserve pour le même spectacle • r[s1] : on lit le spectacle s1, et on s’arrête là (plus assez de places disponibles?) • Un même processus peut effectuer des transactions en série: r[s1]r[c1]w[s1]w[c1] r[s1]r[c2]w[s1]w[c2] r[s1]

17. Exécutions concurrentes • Quand plusieurs programmes clients sont actifs simultanément, les transactions engendrées s’effectuent en concurrence. • On obtient potentiellement un entrelacement des requêtes Serveur r1[s1] w1[s1] r2[c2] r1[c1] r2[s1] Etc. P1 et P2 continuent À s’exécuter … P1 met à jour Le spectacle s1 P1 lit le spectacle s1 P2 lit le Client c2 P2 lit le Client c1 P1 lit le Client c1 • Fait: les exécutions concurrentes non contrôlées sont source d’anomalies.

18. Propriétés des transactions • Un système relationnel garantit un ensemble de propriétés rassemblées sous l’acronyme ACID. • A = Atomicité. Une transaction est validée complètement ou pas du tout. • C = Cohérence. Une transaction mène d’un état cohérent à un autre état cohérent. • I = Isolation. Une transaction s’exécute comme si elle était seule. • D = Durabilité. Quand le commit s’exécute, ses résultats sont définitifs. • Essentiel à retenir: l’isolation peut n’être que partielle, pour des raisons de performance.

19. Pause … • 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?