UE NSY107. Gestion des données dans un contexte réparti

Transcription

1 UE NSY107 Gestion des données dans un contexte réparti CNAM Aquitaine Eric Cariou Université de Pau et des Pays de l'adour UFR Sciences Pau Département Informatique 1

2 Architecture N tiers Gestion de données Généralement une couche dédiée à la gestion des données Fichiers binaires, textes XML Base de données relationnelle La couche donnée peut aussi être décomposée en plusieurs parties Plusieurs bases de données A faire si possible apparaître comme une base unique Problème d'accès concurrent à distance aux mêmes données 2

3 Accès à distance Deux modes de gestion de données dans un contexte distribué «Simple» accès à distance à des données Les données se trouvent sur une autre machine On y accède à distance, via par exemple du client / serveur standard Ex: requêtes SQL sur une base de données se trouvant sur une autre machine via JDBC Problèmes à gérer Accès concurrents aux données par plusieurs clients à la fois Nécessite des transactions Données distribuées Regroupement logique de plusieurs bases / sources 3

4 Données distribuées 4

5 Données distribuées Plusieurs bases de données que l'on va faire coopérer Avec ou sans faire apparaître un schéma commun / une base globale virtuelle Sans : concept de multibase, ensemble de bases de données (hétérogènes) que l'on fait interopérer via un langage commun Avec : bases de données fédérées ou SGBDR SGBDR : Système de Gestion de Base de Données Répartie (ou Distribuée) DDBMS : Distributed DataBase Management System Vision globale uniforme d'une base de données Physiquement constituée d'un ensemble de SGBD Logiquement présentée comme un ensemble unique à l'utilisateur L'utilisateur doit pouvoir faire des requêtes sur la base globale sans avoir à connaître la gestion physique et la répartition des données Transparence de la distribution et de la localisation 5

6 Données distribuées Problèmes à gérer Accès concurrents aux données Là aussi on utilisera des transactions Création logique de la base globale Accès à toutes les données, pas de duplication de données, pas d'incohérences... Conception de la base Faire apparaître logiquement la base comme globale et unique du point de vue des requêtes Nécessite outils dédiés Intégré en général dans les SGBD courants Tout comme les moteurs de transaction 6

7 Approche ascendante Données distribuées Part d'un ensemble de tables et en détermine un schéma global Conception d'une nouvelle base à partir de bases existantes Fédération de bases de données avec gestion de l'hétérogénéité Schéma global BD1 BD2 BD3 7

8 Approche descendante Données distribuées Conçoit une base globale avec ses décompositions en sous-bases La base globale est fragmentée de façon à organiser les données sur des bases physiques différentes Pour profiter d'une approche distribuée Schéma global BD1 BD2 BD3 8

9 Fragmentation Fragmentation de tables Décompose une table en plusieurs tables Les tables pouvant être gérées sur des machines différentes, par des SGBD différents Fragmentation verticale Décompose par groupe d'attributs On recompose par jointure Fragmentation horizontale Décompose par lignes Le schéma reste le même, on recompose par union Fragmentation mixte A la fois verticale et horizontale 9

10 Fragmentation Exemples de fragmentations avec table personne : (short id, varchar(20) nom, short age) Fragmentation horizontale Id Nom Age 1 Saturnin 42 2 Germaine 31 3 Roger 43 4 Sigfried 32 Id Nom Age 1 Saturnin 42 2 Germaine 31 Id Nom Age 3 Roger 43 4 Sigfried 32 10

11 Fragmentation Exemple de fragmentation verticale Doit forcément conserver la clé de la table dans toutes les décompositions (ici id) Sinon ne pourra pas recomposer la table globale (via une jointure sur la clé) Id Nom Age 1 Saturnin 42 2 Germaine 31 3 Roger 43 4 Sigfried 32 Id Nom 1 Saturnin 2 Germaine 3 Roger 4 Sigfried Id Age

12 Fragmentation Possibilité de sous-fragmenter à plusieurs niveaux Id Nom Age 1 Saturnin 42 2 Germaine 31 3 Roger 43 4 Sigfried 32 Jointure Id Nom 1 Saturnin 2 Germaine 3 Roger 4 Sigfried Id Age Union Id Age

13 Fragmentation Doit faire attention à l'intégrité des données Une fois faites les jointures (vertical) et les unions (horizontal) de toutes les fragments on doit retrouver la base originale Performance / optimisation La décomposition permet principalement d'optimiser l'accès aux données Assurer la rapidité d'accès aux données selon la localisation des clients Répartir la charge des requêtes sur plusieurs bases Spécialiser certaines bases sur certaines types / parties des données Ne doit donc pas décomposer n'importe comment Mais difficile de déterminer la meilleure décomposition 13

14 Propriétés données distribués Le système global doit assurer, de préférence, un certain nombre de propriétés Autonomie locale Les données physiquement présentes sur un site sont gérées par ce site Pas de contrôle centralisé Fonctionnement ne doit pas dépendre d'un site central Continuité de service Limite au plus la non disponibilité du système, de l'accès aux données Transparence à la localisation Accès aux données indépendamment de leur localisation, comme si tout était localisé sur le client 14

15 Propriétés données distribués Transparence à la fragmentation La manière dont les tables sont fragmentées / décomposées n'a pas d'influence sur l'accès aux données Le client accède aux données comme si elle n'étaient pas fragmentées Transparence de la réplication Pour des raisons de fiabilité, peut dupliquer les données ou une partie des données Ne doit pas avoir d'influence sur l'accès aux données par le client Transparence également Aux systèmes d'exploitation, au matériel, au réseau, aux SGBD utilisés Doit être capable d'effectuer Transactions distribuées, gestion de réplication 15

16 Transaction 16

17 Transaction Transaction Exécution atomique d'une séquence d'action Dans notre cas, sur une (ou plusieurs) base(s) de données Résultats possibles Pas de problème : toutes les actions sont réalisées Il y a un problème avec un ou plusieurs actions : aucune action n'est réalisée au final, la séquence n'est pas exécutée En pratique, cela nécessite d'annuler l'effet d'actions déjà effectuées le cas échéant Principe fondamental : atomicité de la transaction Les actions de la transactions sont toutes exécutées ou aucune, interdiction d'être dans un état où certaines sont faites et pas d'autres 17

18 Transaction Propriétés d'une transaction Propriétés ACID [Härder & Reuter, 83] Atomicité Tout ou rien : l'action de la transaction est entièrement réalisée ou pas du tout, pas d'intermédiaire à moitié fait Cohérence L'exécution d'une transaction fait passer le système d'un état cohérent à un autre Isolation Les transactions n'interfèrent pas entre elles Durabilité Les effets de la transaction sont enregistrés de manière permanente 18

19 Transaction Deux «types» principaux de transaction Exécution d'une séquence de plusieurs actions par un processus sur une base de données Doit faire plusieurs actions d'un seul bloc ou aucune Exécution d'une même action sur plusieurs bases Exemple classique de la réplication Plusieurs bases physiques qui contiennent les mêmes données dupliquées pour assurer de la fiabilité en cas de crash Si on modifie une donnée sur une base, on doit modifier la copie de cette donnée sur toutes les bases Sinon on se retrouve dans un état incohérent Autres types de transactions Exécution d'une même séquence de plusieurs actions sur plusieurs bases Décomposition de la séquence : exécution de certaines actions sur une base et d'autres actions sur d'autres bases... 19

20 Transaction : exemple Transfert d'argent d'un compte bancaire vers un autre Requière un débit puis un crédit Il faut faire les 2 actions ou aucune sinon on se retrouve dans un état incohérent Begin Transaction Debiter (#1244, 1000 ) Crediter (#8812, 1000 ) End Transaction Si la base de gestion des comptes bancaires est dupliquée Cette séquence d'action doit être exécutée sur toutes les bases ou sur aucune 20

21 Transaction : exemple ajout personne Gestion de personnes vu en atelier Méthode métier d'ajout de personne public int addpersonne(personne p) Contrainte : ne doit pas avoir deux personnes identiques (même nom et age) dans la base Quand on ajoute une personne On regarde si cette personne existe déjà, et si c'est le cas, on retourne l'identifiant de cette personne Sinon, on rajoute la personne dans la base avec un identifiant pas encore utilisé et on retourne cet identifiant Doit donc assurer l'exécution atomique de la séquence suivante 1. Rechercher si la personne existe déjà 2. Créer un nouvel identifiant unique 3. Ajouter la personne dans la base avec cet identifiant Note : les 2 dernières étapes ne sont pas forcément exécutées selon le résultat de la première 21

22 Transaction : exemple ajout personne Exemple de problème si non atomicité de la séquence Ajout de 2 personnes en même temps par 2 clients Peut aboutir à une incohérence des identifiants choisis Ordonnancement temporel possible de 2 ajouts de personne Client A : ajout de «Germaine, 23 ans» Client B : ajout de «Saturnin, 45 ans» On suppose ici que le plus grand identifiant utilisé dans la base est 7 temps Client A 1. Recherche de Germaine : échec 2. Récupère le plus grand id : 7 3. Ajout de Germaine avec id + 1 = 8 Client B 1. Recherche de Saturnin : échec 2. Récupère le plus grand id : 7 3. Ajout de Saturnin avec id + 1 = 8 On a ajouté deux personnes avec le même identifiant! En pratique, le SGBD rejettera le deuxième ajout pour violation de la contrainte d'unicité sur la clé primaire (l'identifiant de la personne) 22

23 Ajout personne : données centralisées Data Manager, avec gestion locale des données et méthodes appelables à distance via Java RMI public class DataManager implements IPersonne { // mémorise le dernier identifiant utilisé protected int dernieridentifiant = 0; // liste des personnes protected HashMap<Integer, Personne> personnes; public synchronized int addpersonne(personne p) throws RemoteException { // si la personne est déjà dedans : retourne son identifiant if (personnes.containsvalue(p)) { return (getpersonnekey(p)).intvalue(); } // elle n'y était pas, on la rajoute en incrémentant le dernier identifiant utilisé dernieridentifiant++; personnes.put(new Integer(dernierIdentifiant), p); return dernieridentifiant; } 23 (...)

24 Ajout personne : données centralisées Gestion de la transaction Mot clé «synchronized» dans la signature de la méthode addpersonne Mécanisme Java qui interdit d'appeler en même temps des méthodes marquées par synchronized Si un client est en train d'appeler la méthode addpersonne, alors un autre client ne pourra pas l'appeler en même temps Devra attendre la fin de l'exécution complète de la première méthode avant de commencer la seconde exécution Assure donc ici de manière simple la cohérence de la liste des personnes On marquera toutes les méthodes d'accès aux données avec «synchronized» 24

25 Ajout personne : accès JDBC au SGBD Autre implémentation de la gestion de personnes Via un SGBD Le data manager envoie des requêtes SQL via JDBC sur le SGBD Schéma général de addpersonne(personne p) 1. SELECT ID FROM PERSONNE WHERE NOM = p.getnom() AND AGE = p.getage() Si le SELECT retourne quelque chose, c'est l'identifiant de la personne déjà présente : on le retourne. Sinon, on continue et exécute les actions 2 et 3 2. SELECT MAX(ID) FROM PERSONNE maxid Récupére le plus grand identifiant utilisé dans la base 3. maxid = maxid + 1 INSERT INTO PERSONNE VALUES (maxid, p.getnom(), p.getage() ) Ajoute la personne dans la base avec son identifiant 25

26 Ajout personne : accès JDBC au SGBD Sur le data manager Si la méthode addpersonne est marquée comme «synchronized», on interdit à 2 clients du data manager de faire 2 appels en parallèle Assure la transaction de ce point de vue là, comme précédemment Problème C'est géré uniquement au niveau du data manager Rien n'interdit à un autre élément ailleurs de faire une requête à distance sur le SGBD (et donc sans passer par le data manager) On ne peut donc pas assurer que la cohérence sera respectée La transaction doit donc être gérée par l'élément qui modifie directement les données Ici le SGBD 26

27 Ajout personne : accès JDBC au SGBD Fonctionnement par défaut de JDBC Valide (commit) automatiquement chaque requête Transaction pour un groupe de requêtes Désactiver le commit automatique Effectuer les actions Faire le commit explicitement Schéma global, s'appliquant sur l'objet de connexion au SGBD connection.setautocommit(false); // exécuter des requêtes (...) // commit explicite connection.commit(); // on repasse dans le mode autocommit connection.setautocommit(true); 27

28 Transaction distribuée Transaction distribuée Des éléments logiciels / processus distribués effectuent tous l'action qui leur est demandée ou aucun ne la fait Exemple L'action peut être la même pour tous ou différer selon les processus Retrait sur un compte bancaire Avec redondance de la base gérant les comptes Le serveur gérant les comptes est dupliqué (une ou plusieurs fois) pour augmenter la fiabilité en cas de panne Quand un processus client demande à faire un retrait sur son compte, deux résultats possibles Le retrait est fait chez tous les serveurs Le retrait n'est fait chez aucun serveur Il faut en effet assurer la cohérence des données stockées entre les serveurs Dans les deux cas, le client est averti de ce qu'il s'est passé 28 Sauf si limite de l'algorithme utilisé dans un certain contexte de faute

29 Validation atomique Validation atomique Au coeur de la problématique de transaction distribuée Protocole de coordination entre processus Se mettent d'accord sur la faisabilité de la transaction Détermination d'une décision globale entre Valider : l'action de la transaction sera exécutée par tous les processus Annuler : aucune action ne sera exécutée par aucun processus Existe de nombreux protocoles dont Validation à 2 phases : 2 phases commit (2PC) Le plus utilisé en pratique mais n'assure pas la terminaison Validation à 3 phases : 3 phases commit (3PC) Extension du 2PC qui assure la terminaison 29

30 Validation atomique Propriété d'un protocole de validation atomique Validité La décision est soit valider, soit annuler, et si un processus décide de valider, alors tous les processus avaient voté «oui» Intégrité Un processus décide au plus une fois Accord (uniforme) Tous les processus (corrects ou non) prendront la même décision Terminaison Tout processus correct décide en un temps fini Non-trivialité Si tous les processus votent «oui» et qu'il n'y a pas de panne, alors la décision est de valider Propriété servant à rejetter la solution triviale de décision systématique d'annuler 30

31 Validation atomique Validation atomique est simple a priori Demander l'avis de tous les processus sur la faisabilité de l'action Si tous les processus répondent «je peux le faire» La décision est de valider, chacun exécute l'action Sinon, si au moins un processus avait répondu qu'il ne pouvait pas effectuer l'action La décision est d'annuler, personne n'exécute l'action Mais devient bien moins simple dans un contexte de fautes... Dans ce qui suit, description des algorithmes 2PC et 3PC Sera une introduction à l'algorithmique distribuée Avec contexte de fautes suivant Pannes franches de processus mais avec reprise possible Système synchrone (connaissance des temps max de propagation des messages) 31

32 Principe d'aller / retour La détection d'un problème avec un élément passe par un aller retour de message On envoie un message à un élément On attend sa réponse dans un intervalle de temps (délai de garde) Estimé à 2 fois le temps de transit d'un message (+ delta éventuel) Si pas reçu de réponse avant l'expiration du délai de garde Message perdu ou l'élément avec qui on communique est planté Pb dans un système asynchrone : estimation du délai de garde délai de garde rien reçu : pb de communication Pj Pi aller retour aller retour (perdu) 32

33 Validation atomique : 2PC Deux types d'éléments Un processus coordinateur qui lance et coordonne la réalisation de la validation atomique L'ensemble des processus participants à la transaction On demandera à chacun d'entre eux s'il peut ou pas réaliser l'action Validation à 2 phases (2PC) Première phase : demande de vote et réception des résultats Deuxième phase : diffusion de la décision à tous et exécution de l'action chez les processus le cas échéant 33

34 coordinateur processus Pi Validation atomique 2PC 1 demande vote Validation à 2 phases (2PC), cas nomimal, sans erreur 1. Le coordinateur envoie une demande de vote à tous les processus 2 oui/non valider ou annuler délai de garde 2. Chaque processus étudie la demande selon son contexte local et répond oui ou non (selon qu'il peut ou pas exécuter la requête demandée) 3. Quand le coordinateur a reçu tous les votes, il envoie la décision finale : valider si tout le monde a répondu oui ou annuler si au moins un processus a répondu non 4. Chaque processus exécute la requête s'il reçoit valider ou ne fait rien s'il reçoit annuler, et envoie un acquittement au coordinateur pour lui préciser qu'il a reçu la décision globale 3 4 ack 5 34

35 2PC : gestion des problèmes Gestion des problèmes, cadre général Si un délai de garde expire, c'est que l'élément dont on attendait un message ne l'a pas envoyé On suppose alors qu'il est en panne Dans un contexte où la panne peut être temporaire et le processus peut être relancé Peut renvoyer un message au processus Mais pas certain que le procesus sera remis sur pied et ne sait pas, si ça arrive, combien de temps il faudra attendre Un processus peut enregistrer son état ou ses décisions, il saura alors ce qu'il avait décidé s'il repart Un processus qui ne reçoit pas de réponse du coordinateur peut interroger les autres processus Selon les cas, certains processus connaissent des choses qu'on devrait également savoir, on peut leur demander 35 Mais pas sûr que quelqu'un ait l'information cherchée

36 2PC : gestion des problèmes Gestion des problèmes, coté coordinateur Phase de vote, expiration du délai de garde en 3 : un processus Pi n'a pas répondu Considère qu'il est planté... donc pas capable d'effectuer l'action La décision globale est alors d'annuler la transaction Variante si possibilité de reprise d'un processsus : relancer la requête à Pi Phase de décision, expiration du délai de garde en 5 : pas reçu tous les acquittements des processus Le coordinateur ne sait pas si tout le monde a reçu la décision Si c'était annuler : pas si grave, il ne fallait rien faire Pb tout de même en cas de reprise d'un processus planté qui avait choisi oui : ne connait pas la décision globale Peut la demander à d'autres processus ou au coordinateur Si c'était valider : problème important car n'est pas assuré que toutes les actions ont bien été réalisées Dans les 2 cas, on peut renvoyer la décision globale aux processus n'ayant pas répondu en espérant recevoir les acquittements 36

37 2PC : gestion des problèmes Gestion des problèmes, coté processus Expiration du délai de garde en 4 sur Pi : pas reçu la décision globale de la part du coordinateur Si le Pi avait voté non Pas un problème, car si au moins un processus vote non, la décision globale est d'annuler et comme le processus sait qu'il a voté non, il connait la décision globale qui est forcément d'annuler N'a pas besoin de recevoir l'information de la part du coordinateur Si Pi avait voté oui Ne peut pas savoir quoi faire : ne sait pas si tout le monde avait voté oui ou si au moins un processus avait voté non Le problème est que le coordinateur est planté A-t'il planté avant de prendre la décision globale? Personne alors ne sait ce qui devait être décidé A-t'il planté pendant qu'il envoyait la décision globale? Certains processus ont alors reçu la décision globale (mais peuvent être plantés depuis) 37

38 2PC : gestion des problèmes Gestion des problèmes, coté processus Non réception de la décision globale en 4 sur Pi (fin) Pour connaître la décision globale, Pi peut interroger les autres processus Mais pas certain de recevoir une réponse, peut-être que personne ne la connaît Et de manière plus générale, les processus ne se connaissent pas forcément entre eux Si le coordinateur reprend son exécution après sa panne, il peut relancer le protocole là où il s'était arrêté Arrivera alors à informer les processus et donc Pi Reste toujours des cas où un processus ne connaîtra pas la décision finale en ayant voté oui Mais Pi ne peut pas choisir seul ce qu'il faut faire Car dans le cas où certains processus ont reçu la décision du coordinateur Si Pi décide d'exécuter l'action alors que la décision était annuler ou s'il décide de ne pas exécuter l'action alors que la décision était valider Etat incohérent, tous les procesus ne feront pas la même chose! 38

39 2PC : coordinateur Diagramme d'état du coordinateur 39

40 2PC : processus Diagramme d'état d'un processus Pi 40

41 Validation atomique : vers la 3PC Conclusion sur la 2PC La terminaison n'est pas assurée, le protocole est potentiellement bloquant Un processus peut se retrouver dans un état où il ne sait pas quoi faire Le problème général est qu'entre les moments 2 et 4, les processus sont dans une zone d'incertitude Ne savent pas ce qui a été choisi globalement La validation atomique à 3 phases rajoute une étape où on informe les processus de la décision globale avant de leur demander de la réaliser Validation atomique à trois phases (3PC) Première phase : demande de vote et attente des votes (idem que pour 2PC) Deuxième phase : envoie à tous les processus de la décision globale et attente des acquittements de la réception Troisième phase : diffusion de la demande d'exécution de la requête (sauf si décision annuler) 41

42 coordinateur processus Pi Validation atomique : 3PC 1 demande vote 2 oui/non préparer ou annuler Validation à 3 phases (3PC), cas nomimal, sans erreur 1. Le coordinateur envoie une demande de vote à tous les processus 2. Chaque processus étudie la demande selon son contexte local et répond oui ou non 3. Quand le coordinateur a reçu tous les votes, il envoie 3 Soit annuler si un processus avait voté non La validation est alors terminée, pas d'autres échanges de messages Soit une demande aux processus de se préparer à exécuter la requête 4. Chaque processus envoie un acquittement au coordinateur de la réception de cette demande 5. Une fois tous les acquittements reçus, le coordinateur diffuse la validation finale Chaque processus exécute alors la requête 4 5 ack valider 6

43 3PC : gestion des problèmes Gestion des problèmes, coté coordinateur Phase de vote, expiration du délai de garde en 3 : un processus Pi n'a pas répondu Idem que pour 2PC : la décision globale est d'annuler Phase de décision, expiration du délai de garde en 5 : un processus Pi n'a pas envoyé son acquittement de pré-validation Pi a planté et ne pourra donc pas valider l'action Si possibilité de reprise, peut essayer de lui renvoyer le message de préparation Ou il aura de toute façon enregistré le fait qu'il avait voté oui Coordinateur sait que tous les autres processus avait forcément voté oui (sinon le coordinateur ne serait pas dans cet état de pré-validation en 5) Peut donc tout de même lancer l'ordre de validation à tous les processus Note Peut rajouter des acquittements identiques pour l'annulation et validation globale envoyés des processus au coordinateur comme en 2PC 43 Gérera les problèmes comme en 2PC

44 3PC : gestion des problèmes Gestion des problèmes, coté processus Expiration du délai de garde en 4 sur Pi : pas reçu la décision globale de la part du coordinateur Comme en 2PC, Pi ne connaît pas la décision globale et ne peut la déterminer Lance alors un protocole de terminaison, dont la version la plus courante est l'élection d'un nouveau coordinateur ou la relance du coordinateur en panne Ce dernier reprendra le protocole de validation Expiration du délai de garde en 6 sur Pi : pas reçu la demande de validation de la part du coordinateur A la différence du 2PC, Pi connaît la décision globale qui est forcément de valider, il peut donc quoiqu'il arrive exécuter l'action Sauf qu'il ne sait pas si tout le monde l'exécutera (vu que seulement certains processus ont pu recevoir la validation finale de la part du coordinateur avant qu'il ne plante) On lance alors là aussi le protocole de terminaison (nouveau 44 coordinateur)

45 3PC : gestion des problèmes Gestion des problèmes : nouveau coordinateur Principe général est de retrouver l'état dans lequel le coordinateur était avant de planter Si lancement d'un nouveau coordinateur : doit interroger des processus pour le déterminer Si au moins un processus dans l'état annuler : passe dans l'état annuler et envoie une décision d'annulation globale à tous les processus Si certains processus dans état valider : la décision globale est forcément de valider et le message valider a déjà été envoyé à certains mais pas reçu par tous Envoyer message de validation à tous Si certains processus dans l'état de pré-validation et d'autres dans l'état d'attente (juste après le vote) : la décision globale est forcément de valider mais tout le monde n'a pas reçu le message de préparation Reprendre le protocole au niveau de l'envoi du message préparer Tous les processus dans l'état d'attente : avaient tous voté oui Reprendre le protocole au niveau de l'envoi du message préparer 45

46 3PC : gestion des problèmes Gestion des problèmes : nouveau coordinateur (fin) Si relance du coordinateur : simple, il avait enregistré son dernier état avant de planter Reprend alors où il s'était arrêté Si dans l'état d'attente des votes Annule la transaction : envoyer annuler Si dans l'état de pré-validation ou de validation Sait que la décision de valider avait été prise Renvoie les messages de préparation et/ou de validation selon l'état 46

47 3PC : coordinateur Diagramme d'état du coordinateur 47

48 3PC : processus Diagramme d'état d'un processus Pi 48

49 Validation atomique : 3PC Conclusion 3PC Si un processus reçoit un «préparer» de la part du coordinateur, il sait alors que quoiqu'il arrive tous les processus ont décidé de valider la requête Principe est qu'un coordinateur ou un processus n'a pas de doute sur le fait de transiter vers annuler ou valider Pas de possibilité d'aller vers les 2 états finaux directement Comme on peut l'avoir en 2PC : ex pour processus, état attente de la décision globale a une transition vers valider et une vers annuler Passe notamment par un état de pré-validation avant de valider définitivement 49

50 Algorithmique distribuée Quelques mots sur l'algorithmique distribuée Développement et conception d'algorithmes dans le contexte des systèmes distribués Adaptation de problèmes classiques dans un contexte distribué ou développement d'algorithmes dédiés au distribué Souvent algorithme simple dans un contexte fiable (pas de plantage de processus, pas de perte de messages) Mais adaptation généralement complexe voire impossible dans un contexte de faute Type de faute ou problèmes à prendre en compte Perte de message Processus qui plante Processus qui ne fait pas ce qu'il devait faire Pas de bornes sur les temps de propagation des messages 50...

51 Algorithmique distribuée Ex. du protocole de validation à 2 phases Simple / trivial dans un contexte sans faute Mais n'assure déjà pas de se terminer même avec peu de fautes possibles Uniquement plantage de processus Autres familles d'algorithmes Exclusion mutuelle Diffusion fiable / atomique Consensus Election d'un maître Détermination d'un état global... 51

52 Gestion de la concurrence Plusieurs clients peuvent demander à exécuter des transactions de manière simultanée sur une même base Doit assurer la cohérence et l'intégrité des données lues et modifiées Cas le plus simple Ex: Data Manager avec méthodes Java marquées comme synchronized Interdiction de commencer à exécuter une méthode (une transaction donc) tant qu'une méthode est en cours et n'est pas terminée Marche bien mais est très restrictif Ordonnancement et séquentialité totale des transactions Pas de possibilité de les entremêller même si sont indépendantes Pourrait être plus flexible et plus fin dans la gestion concurrente Autoriser d'avoir des transactions en parallèle selon ce qu'elles font Exemple trivial : si 2 transactions traitent des données qui n'ont rien en commun, elles sont indépendantes et peuvent être réalisées en 52 parallèle

53 Gestion de la concurrence Intérêt d'avoir des transactions parallèles Performances Séquentialité pure peut être très couteuse en terme de temps d'exécution Propriété à assurer Sérialisabilité L'exécution parallèle des transactions doit aboutir à un résultat équivalent à leur exécution séquentielle Principe des verrous Une transaction pose un verrou sur une donnée X qu'elle va utiliser Si verrou pour une lecture de X, d'autres transactions peuvent poser des verrous en lecture sur X 53 Si verrou en écriture sur X, aucun autre verrou possible

54 Gestion de la concurrence Protocole de verrouillage à 2 phases (2PL) Phase 1 : pose les verrous sur les données auxquelles on veut accèder Phase 2 : quand on (commence à) relache(r) des verrous, on ne peut plus en acquérir d'autres Exécution d'une transaction : respect 2PL Pose les verrous sur les données requises En attendant éventuellement que les données verrouillées par d'autres transactions soient libres Exécute des opérations sur les données Une fois qu'on a tous les verrous sur toutes les données Libération des verrous des données A la fin de la transaction ou au fur à mesure de l'utilisation des données, quand on en a plus besoin 54

55 Gestion de la concurrence Problème de l'utilisation des verrous Possibilité d'interblocage Transaction 1 : verrou en écriture sur A, en lecture sur B Transaction 2 : verrou en écriture sur B, en lecture sur A Ordonnancement possible 1. T1 : verrouille A 2. T2 : verrouille B 3. T1 : attend la libération de B & T2 : attend la libération de A Chaque transaction attend la libération d'une donnée par l'autre transaction pour pouvoir continuer et ensuite libérer ses données Les 2 sont bloquées! Famine Si une donnée est très souvent utilisée par beaucoup de transactions Il se peut que certaines transactions n'aient jamais accès à 55 cette donnée, passeront toujours après les autres transactions

56 Gestion de la concurrence Interblocage : existe des solutions pour l'éviter Prévention Attendre que toutes les données soient verrouillables et poser tous les verrous en même temps Utiliser des estampilles (dates logiques) pour gérer un ordre de priorité sur les verrous Détection Si 2 transactions veulent poser un verrou sur une même donnée, la plus ancienne aura la priorité Déterminer le graphe d'attente des données S'il y a un cycle : interblocage 56

57 Gestion de la concurrence Interblocage est d'autant plus problématique avec plusieurs bases distribuées Les verrous d'une transaction sont posés sur des données de plusieurs bases Doit savoir si telle ou telle donnée est verrouillée sur telle ou telle base Nécessité d'avoir une connaissance globale à partir de connaissances locales Localement, on connaît les verrous sur la base gérée Deux façons de gérer les verrous multi-base Centralisé : un serveur gère les connaissances sur tous les verrous de toutes les transactions Inefficace en pratique, goulot d'étranglement Décentralisé : chaque base gère ses verrous sur ses données et utilisation d'algorithmes dédiés pour gestion des verrous57

58 Réplication 58

59 Principe de la réplication Réplication Une même base de données est physiquement dupliquée en une ou plusieurs instances Permet de conserver les données en cas de crash de la base Permet de basculer immédiatement sur une autre base en cas de crash Continuité du service sans perte de données Nécessite pour cela Cohérence permanente des bases Chaque base doit contenir les mêmes données en permanence 59

60 Réplication TODO 60

61 Frameworks de persistance 61

62 Problématique Exemple d'application vue en atelier Programmation partie métier / client en Java On manipule des objets pour contenir des données Exemple public class Personne { String nom; Int age; // méthodes d'accès aux attributs age et nom } Si stocke les données directement en Java, ensemble des personnes Hashmap<Integer, Personne> personnes; Stockage donnée dans un SGBD avec accès en SQL aux données Stockage sous forme de tables SQL personne (int id, varchar(20) nom, int age) 62

63 Problématique Code pour récupérer une personne via son id Pur Java public Personne getpersonne(int id) throws InvalidIdException { } // si la personne n'existe pas, lève exception if (! (personnes.containskey(new Integer(id)))) throw new InvalidIdException("invalid index value : "+id); // sinon, retourne son identifiant return (personnes.get(new Integer(id))); Manipule directement la HashMap personnes Code «naturel», programmation Java standard 63

64 Problématique Java avec stockage BDD et accès via JDBC public int getid(personne p) throws InvalidIdException { try { Statement requete = connection.createstatement(); // requête SQL pour rechercher la personne ResultSet result = requete.executequery("select NOM, AGE FROM PERSONNE WHERE ID=\""+id+"\""); // regarde si la requête a renvoyé quelque chose : si ça n'est pas // le cas, la personne n'existait pas if (!result.next()) throw new InvalidIdException("invalid index value : "+id); } // sinon, à partir du résultat retourné, instancie une personne // avec les valeurs du résultat else return new Personne(result.getInt("age"), result.getstring("nom")); } catch(sqlexception e) { System.err.println(e); } 64

65 Problématique Java avec stockage BDD et accès via JDBC Nécessite des requêtes SQL Utilisation d'un framework dédié : JDBC Sort du format «standard» de représentation Java des données Une requête de type SELECT retourne un ResultSet C'est à dire un ensemble de ligne de plusieurs colonnes On accède aux éléments du ResultSet en naviguant selon les lignes et les colonnes Peu pratique mais difficile de faire autrement vu ce que retourne de manière native les requêtes SQL Sauf à passer par des SGBD objet-relationnel 65

66 Problématique Java avec stockage BDD et accès via JDBC Au dela de l'accès à faire à distance Qui complexifie forcément les choses mais ne peut pas y couper Représentation des données très différentes Coté BDD Structure en table avec langage de requête dédié Récupère toujours une «sous-table» via le résultat de l'exécution d'une requête de type SELECT Coté Java Instances de classe (Personne ici) : objets Les objets sont associés entre eux et forment un graphe d'objet dans l'application? 66

67 Problématique Doit être capable de faire la correspondance d'une représentation à une autre Pas simple : d'une représentation objet à une représentation relationnelle Solution Le faire à la main Comme pour notre exemple Utiliser une base de données relationnelle orientée objet Coté BDD, la structure de stockage intégrera des concepts objets Passage plus facile du programme au stockage dans la base Mais toujours besoin de faire des requêtes explicites Utiliser un framework de persistance 67

68 Framework de persistance Principes S'abstraire des problèmatiques de stockage des données Définition de mappings entre La structure des classes utilisées dans l'application Le stockage physique utilisé par le support de persistance Généralement, un SGBD relationnel Lors de l'exécution de l'application Création, suppression, manipulation, collections d'objets... gérés de manière classique, programmation «standard» Le framework fait le lien entre le graphe d'objet en mémoire dans l'application et le stockage physique Typiquement : envoi de requête SQL au SGBD pour récupérer des données, les modifier, les ajouter / supprimer 68

69 Framework de persistance Intérêt des frameworks de persistance Plus besoin de se préoccuper du stockage physique et des problèmes de correspondance Comme on le voit dans notre exemple de l'atelier Ecriture des requêtes SQL via JDBC est assez lourd L'implémentation des accès aux données peut représenter un temps important lors du développement d'une application On gagne ainsi en temps de développement et en indépendance des supports physiques Suffit de changer les règles de mappings sans modifier le code de l'application Hibernate Framework de persistance libre pour le monde Java NHibernate pour.net Standard de fait, très utilisé dans l'industrie Utilisé également par JPA (framework standard de persistance sous Java Java Persistence API) 69

70 Hibernate Principes généraux d'hibernate Définition des structures de données / entités manipulées Via des fichiers XML Ou des classes Java annotées A partir de cela, peut générer la représentation Java de l'entité Un POJO : Plain Old Java Objet Classe Java totalement standard avec définition d'attributs, d'accesseurs, de constructeurs pour gestion données de l'entité Ne s'appuie donc pas sur des framework ou librairie particuliers, contrairement par exemple aux entités d'ejb Définition, en XML, d'un ensemble de fichiers de configuration Mapping d'une entité vers un support physique Configuration générale de l'accès au support physique 70

71 Hibernate Principes généraux d'hibernate (fin) Pour gérer la persistance, on crée une session Hibernate Via cette session, peut Récupérer sous forme d'instances de POJO des données stockées par le support physique Utilisation notamment d'hql (Hibernate Query Language) Modifier le contenu de ces POJO, leurs associations, en ajouter, en supprimer,... Le framework fera le lien entre les modifications locales et le stockage physique Fonctionne en mode transactionnel pour les modifications 1. Création d'une transaction 2. Modification des objets 3. Validation de la modification (commit) ou annulation en cas 71 de problème (rollback)

72 Exemple Hibernate Exemple de gestion de sports et de disciplines Un sport contient plusieurs disciplines Tables du SGBD (Oracle ici) sport (code_sport, intitule) discipline (code_discipline, intitule, code_sport) Ici, on choisira d'avoir, coté Java, des objets de type Sport et Discipline Avec les mêmes structures de données que ce qui est stocké dans la base Mais ça n'est pas une obligation d'avoir exactement la même chose 72

73 Exemple Hibernate Contenu des tables pour l'exemple Table sport code sport intitule athletisme 2 ski 3 natation Table discipline code code discipline intitule sport metres metres 1 3 saut en hauteur 1 4 saut en longueur m 4 nages m papillon 3 7 marathon 1 73

74 Hibernate : ex. configuration générale Configuration générale d'hibernate <hibernate-configuration> <session-factory> <property name="hibernate.dialect">org.hibernate.dialect.oracledialect</property> <property name="hibernate.connection.driver_class">oracle.jdbc.oracledriver</property> <property name="hibernate.connection.url">jdbc:oracle:thin:@scinfe099:1521:etud10</property> <property name="hibernate.connection.username">ecariou</property> <property name="hibernate.connection.password">toto</property> <property name="hibernate.show_sql">true</property> <mapping class="data.sport" file="" jar="" package="" resource="data/sport.hbm.xml"/> <mapping class="data.discipline" file="" jar="" package="" resource="data/discipline.hbm.xml"/> </session-factory> </hibernate-configuration> On y trouve, notamment Les paramètres de connexion à la base Oracle (avec le type de driver à utiliser) On peut voir que l'accès en pratique se fera via JDBC L'association d'un POJO avec son fichier de mapping Ex: data.sport (classe Java) dont le mapping est précisé dans Sport.hbm.xml 74

75 Hibernate : ex. de fichier de mapping Fichier Sport.hbm.xml <hibernate-mapping> <class name="data.sport" table="sport" schema="ecariou"> <id name="codesport" type="short"> <column name="code_sport" precision="4" scale="0" /> <generator class="assigned" /> </id> <property name="intitule" type="string"> <column name="intitule" length="20" /> </property> <set name="disciplines" inverse="true"> <key> <column name="code_sport" precision="4" scale="0" /> </key> <one-to-many class="data.discipline" /> </set> </class> </hibernate-mapping> Dans classe data.sport, attribut «codesport» correspond à la colonne CODE_SPORT de la table SPORT Définition d'un ensemble nommé «disciplines» dans la classe data.sport Jointure avec la table discipline : toutes les disciplines de ce sport 75

76 Hibernate : ex. de POJO POJO d'un sport, généré à partir du fichier de mapping public class Sport implements java.io.serializable { private short codesport; private String intitule; private Set disciplines = new HashSet(0); public Sport() { } public short getcodesport() { return this.codesport; } public void setcodesport(short codesport) { this.codesport = codesport; } public Sport(short codesport) { this.codesport = codesport; } public Sport(short codesport, String intitule, Set disciplines) { this.codesport = codesport; this.intitule = intitule; this.disciplines = disciplines; } Définition des attributs, avec getter et setter associés Définition des constructeurs } public String getintitule() { return this.intitule; } public void setintitule(string intitule) { this.intitule = intitule; } public Set getdisciplines() { return this.disciplines; } public void setdisciplines(set disciplines) { this.disciplines = disciplines; } 76

77 Hibernate : ex. accès aux données Affichage de la liste des sports, avec pour chacun la liste de ses disciplines // création session Hibernate (et donc connexion au serveur Oracle) Session session = (new Configuration().configure().buildSessionFactory()).openSession(); // requête en HQL : récupère la liste de tous les sports, // sous forme d'une liste Java Query query = session.createquery("from data.sport"); List sports = query.list(); // variables utilisées pour le parcourt de la liste des sports Set disciplines; Iterator itsport, itdisc; Sport sport; Discipline disc; 77

78 Hibernate : ex. accès aux données Affichage de la liste des sports, avec pour chacun la liste des disciplines (suite) // parcourt les disciplines itsport = sports.iterator(); while (itsport.hasnext()) { sport = (Sport) itsport.next(); System.out.println(sport.getCodeSport() + " -> " + sport.getintitule()); // récupère l'ensemble des disciplines du sport disciplines = sport.getdisciplines(); itdisc = disciplines.iterator(); } // parcourt les disciplines while (itdisc.hasnext()) { disc = (Discipline) itdisc.next(); System.out.println(" "+disc.getcodediscipline() + " -> "+disc.getintitule()); } 78

79 Hibernate : ex. accès aux données Affichage résultant de l'exécution 1 -> athletisme 1 -> 100 metres 2 -> 200 metres 7 -> marathon 4 -> saut en longueur 3 -> saut en hauteur 2 -> ski 3 -> natation 6 -> 100m papillon 5 -> 100m 4 nages Point intéressant A partir d'un objet de classe Sport, on accède directement à sa liste de discpline via getdisciplines() : ensemble d'objets Les objets sont chargés à partir de la base directement sans besoin de traitement particulier, c'est transparent Si on était passé par du SQL via JDBC, on aurait du faire une requête explicite du type 79 SELECT * FROM DISCIPLINE WHERE CODE_SPORT=XX

80 Hibernate : ex. accès aux données A l'exécution, peut demander à tracer les requêtes SQL effectuées, ce qui donne ici Hibernate: select sport0_.code_sport as CODE1_0_, sport0_.intitule as INTITULE0_ from ECARIOU.SPORT sport0_ 1 -> athletisme Hibernate: select discipline0_.code_sport as CODE2_1_, discipline0_.code_discipline as CODE1_1_, discipline0_.code_discipline as CODE1_1_0_, discipline0_.code_sport as CODE2_1_0_, discipline0_.intitule as INTITULE1_0_ from ECARIOU.DISCIPLINE discipline0_ where discipline0_.code_sport=? 1 -> 100 metres 2 -> 200 metres 7 -> marathon 4 -> saut en longueur 3 -> saut en hauteur (...) Premier SELECT : pour récupérer la liste des sports Deuxième SELECT : pour récupérer la liste des disciplines du sport courant 80

81 Hibernate : ex. accès aux données Autre exemple : ajout d'une discipline au sport natation try { // ouvre la session et une transaction session = (new Configuration().configure().buildSessionFactory()).openSession(); trans = session.begintransaction(); // récupère l'instance de sport correpondant à natation query = session.createquery("select sport from Sport sport where sport.intitule='natation'"); // ajout du relais 4 x 100 dans le sport natation en rendant l'objet persistant disc = new Discipline((short)8, sport, "relais 4 x 100"); session.persist(disc); // commit pour valider physiquement l'ajout trans.commit(); } catch (Exception e) { System.err.println("Erreur Hibernate : " + e); // problème : on annule la transaction trans.rollback(); } session.close(); 81

82 Hibernate : ex. accès aux données Notes sur code d'ajout On crée l'objet discipline «disc» avec l'objet sport en paramètre On passe une référence d'objet, on ne donne pas une clé identifiant un sport comme on le ferait avec SQL On est bien dans de la manipulation «standard» d'objets Le «persist» sur cet objet permet directement, sans traitement supplémentaire, de le rendre persistant Physiquement, l'enregistrer dans la BDD Si on trace les requêtes SQL, on obtient Hibernate: select sport0_.code_sport as CODE1_0_, sport0_.intitule as INTITULE0_ from ECARIOU.SPORT sport0_ where sport0_.intitule='natation' Hibernate: insert into ECARIOU.DISCIPLINE (CODE_SPORT, INTITULE, CODE_DISCIPLINE) values (?,?,?) La première requête est un SELECT qui récupère les données du sport «natation» La deuxième requête est un INSERT qui ajoute la discipline qu'on vient de créer 82

83 Hibernate Conclusion sur Hibernate Framework de persistance très puissant (on n'en a vu qu'une légère introduction) Gestion de multiples supports physiques Indépendance des supports physiques Gestion des caractéristiques objet (héritage, polymorphisme...) Politiques de chargements des objets (à la demande...) Langage de requête HQL Permet vraiment de se consacrer sur la logique métier La gestion des données est (quasiment que) du Java natif, pas à soucier de comment sont gérées et accédées les données Au niveau du programme en tout cas, car il faut quand même concevoir la base de donnée... 83