Les accès concurrents dans les bases de données

Sommaire du document

Dès que nous devons manipuler ou stocker des informations (que ce soit pour la conception d'une application, d'un site dynamique, la mise en place d'un forum, etc.), nous pensons aux bases de données.

Dans le cas d'une application mono-utilisateur, nous ne nous soucions peu des accès concurrents, mais que penser d'une application qui partage la même base de données pour un certain nombre d'utilisateurs ? Nous devons alors prendre en considération d'autres facteurs tels que les performances, les goulots d'étranglement lors de l'accès aux données, et les accès simultanés à une même donnée par plusieurs utilisateurs. Par exemple, Microsoft signale qu'il est fortement déconseillé de travailler avec plus de 10 utilisateurs simultanés avec Access.

Tant que les utilisateurs accèdent aux données en lecture seulement, nous ne risquons rien. Mais dès que les utilisateurs peuvent ajouter, modifier, et/ou supprimer des données, nous risquons d'être confrontés à de nombreux problèmes.

Exemple d'accès concurrents

Deux utilisateurs, Titi et Toto, utilisent en même temps l'application.

  • Titi lit la liste des élèves.
  • Toto lit la liste des élèves.
  • Titi décide de modifier l'élève Jonathan Livingstone
  • Toto supprime l'élève Jonathan Livingstone
  • Titi sauve les modifications apportées : ERREUR ! L'élève n'existe plus dans la base de données.

La situation suivante est encore plus grave :

L'élève Jonathan Livingstone avait obtenu 11/20 pour son test. Jonathan conteste le résultat et Toto son professeur, décide lui ajouter 2 points.
Toto prévient Titi au secrétariat qu'il faut ajouter 2 points à Jonathan.
A la relecture de l'examen, Toto se rend compte que le premier résultat était bon, et décide donc de retirer les 2 points. Seulement, Titi n'a pas effectué la correction de suite : Titi et Toto décident donc d'effectuer les modifications au même moment.

  • Titi lit la liste des élèves.
  • Toto lit la liste des élèves.
  • Titi décide de modifier l'élève Jonathan Livingstone. La cote de Jonathan à ce moment vaut 11.
    Il modifie les points qu'il a obtenu en comportement, et lui ajoute 2 points (11 + 2 = 13).
  • Toto décide de modifier l'élève Jonathan Livingstone. La cote de Jonathan à ce moment vaut 11.
    Il modifie les points qu'il a obtenu en comportement, et lui retire 2 points (11 - 2 = 9).
  • Titi sauve les modifications apportées : 13.
  • Toto sauve les modifications apportées : 9.

Titi et Toto pensent que tout est correct car ils ont chacun effectué leur opération sans message d'erreur.

Et pourtant le résultat n'est pas correct...

Le verrouillage, une solution ?

Nous pouvons décider de verrouiller (lock) l'enregistrement au moment où il est chargé en mode édition.

Si Titi sélectionne l'utilisateur Jonathan Livingstone  en le verrouillant, Toto peut lire les données, mais ne peut ni les modifier, ni supprimer l'utilisateur.

Titi verrouille l'enregistrement pour pouvoir le modifier, mais doit partir régler un autre problème et verrouille son compte en laissant la DB ouverte. Toto ne peut plus modifier les points tant que Titi ne sera pas revenu.

La double transaction

Il existe une autre solution, qui consiste à recharger l'enregistrement juste avant d'effectuer la mise à jour des données. Cette méthode porte le nom de double transaction.

Au moment de sauver les données, une lecture depuis la DB permet de vérifier si la forme initiale correspond aux données actuelles de la DB. Dans le cas contraire, nous avons détecté un accès concurrent.

Cette méthode permet d'éviter les verrouillages, mais exige un surcoût mémoire (car il faut stocker les valeurs initiales) et un accès supplémentaire à la base de données.

Il est aussi possible de quand même verrouiller l'enregistrement au moment de la lecture de vérification, car le temps entre cette deuxième lecture et la sauvegarde des informations est extrèmement court et dépend de l'application et non du temps de réaction de l'utilisateur.

Transaction et roll-back

La notion de transaction est toutefois plus souvent utilisée pour désigner un ensemble d'opérations qui dépendent les unes des autres. Si une des opérations de l'ensemble ne peut être effectuée, le roll-back est un retour à la situation avant de débuter la série d'opérations.

 

Réseaux sociaux

Vous pouvez modifier vos préférences dans votre profil pour ne plus afficher les interactions avec les réseaux sociaux sur ces pages.

 

Nuage de mots clés

9 mots clés dont 0 définis manuellement (plus d'information...).

Avertissement

Cette page ne possède pas encore de mots clés manuels, ceci est donc un exemple automatique (les niveaux de pertinence sont fictifs, mais les liens sont valables). Pour tester le nuage avec une page qui contient des mots définis manuellement, vous pouvez cliquer ici.

Vous pouvez modifier vos préférences dans votre profil pour ne plus afficher le nuage de mots clés.

 

Astuce pour imprimer les couleurs des cellules de tableaux : http://www.gaudry.be/ast-rf-450.html
Aucun commentaire pour cette page

© Ce document issu de l′infobrol est enregistré sous le certificat Cyber PrInterDeposit Digital Numbertection. Enregistrement IDDN n° 5329-11342
Document créé le 20/03/07 03:59, dernière modification le Vendredi 17 Juin 2011, 12:12
Source du document imprimé : http:///www.gaudry.be/sgbdr-concurrence.html
St.Gaudry©07.01.02
Outils (masquer)
||
Recherche (afficher)
Recherche :

Utilisateur (masquer)
Apparence (afficher)
Stats (afficher)
15838 documents
455 astuces.
550 niouzes.
3107 definitions.
447 membres.
8121 messages.

Document genere en :
1,13 seconde

Mises à jour :
Mises à jour du site
Citation (masquer)
Celui qui n'a pas peur n'est pas normal ; ça n'a rien à voir avec le courage.

Jean-Paul Sartre
 
l'infobrol
Nous sommes le Dimanche 28 Mai 2017, 05:16, toutes les heures sont au format GMT+1.00 Heure, heure d'été (+1)