Geen cache-versie.
Caching uitgeschakeld. Standaardinstelling voor deze pagina:ingeschakeld (code LNG204)Als het scherm te langzaam is, kunt u de gebruikersmodus uitschakelen om de cacheversie te bekijken.
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.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 20/03/2007 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/sgbdr-concurrence.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
