Les accès concurrents dans les bases de données
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.
Version en cache
21/11/2024 09:48:00 Cette version de la page est en cache (à la date du 21/11/2024 09:48:00) afin d'accélérer le traitement. Vous pouvez activer le mode utilisateur dans le menu en haut pour afficher la dernère version de la page.Document créé le 20/03/2007, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/sgbdr-concurrence.html
L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.
