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.
English translation
You have asked to visit this site in English. For now, only the interface is translated, but not all the content yet.If you want to help me in translations, your contribution is welcome. All you need to do is register on the site, and send me a message asking me to add you to the group of translators, which will give you the opportunity to translate the pages you want. A link at the bottom of each translated page indicates that you are the translator, and has a link to your profile.
Thank you in advance.
Document created the 20/03/2007, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/sgbdr-concurrence.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
