Table des matières
La manipulation de la concours Dans les applications Web, c'est l'un des sujets auxquels nous devons consacrer un peu de temps de qualité, car en raison de la nature même de l'application, nous pouvons rencontrer des cas dans lesquels plusieurs utilisateurs doivent interagir avec le même élément.En soi est interaction Ce n'est pas un problème, le vrai problème vient quand après avoir modifié ou touché cet élément il faut l'enregistrer dans la base de données et qu'ensuite deux utilisateurs ou plus veulent faire une action sur le même élément en même temps, c'est là notre logique doit définir un comportement pour savoir quelle est la bonne façon de gérer cela.
Comme nous l'avons expliqué au début, le concours C'est lorsque deux ou plusieurs acteurs travaillent sur un élément de notre application, générant une action contre la base de données.
Cas de simultanéitéDes problèmes peuvent survenir lorsque les changements sont conflictuels, par exemple : l'utilisateur A a enregistré une valeur, mais l'utilisateur B était également en train de modifier à ce moment-là et a enregistré une valeur différente, aux yeux de l'utilisateur A son contenu n'a pas été modifié et aux yeux de l'utilisateur utilisateur B, rien ne l'empêchait d'effectuer sa modification.
Ces types de conflits peuvent ternir les performances de notre application aux yeux de l'utilisateur, nous devons donc évaluer si les zones que nous avons vaudront la peine ou non de programmer pour la concurrence.
Voyons quelques types de simultanéité, de cette façon, nous pouvons comprendre un peu plus quel type d'actions nous pouvons exécuter dans nos applications :
Concurrence pessimisteCette approche propose que lors de l'utilisation de la base de données, nous fassions un blocage préventif du registre en cours d'utilisation, nous évitons ainsi que plusieurs utilisateurs modifient la valeur simultanément, le problème est que dans l'environnement Web, il n'est pas possible de l'utiliser à fond, car comme il n'y a pas d'état, nous ne savons pas vraiment si le verrou a été appliqué ou supprimé jusqu'à ce que nous communiquions avec le serveur, générant confusion et lenteur d'utilisation.
Participation optimisteCette autre approche fait plutôt quelque chose d'un peu plus compatible avec le web, lors de la modification, avant d'enregistrer dans la base de données, elle vérifie que les données n'ont pas été modifiées à partir du moment où la lecture a été effectuée, pour cela nous effectuons une comparaison des valeurs d'enregistrement et un champ associé qui porte un horodatage avec date, heure et secondes pour une plus grande précision.
ASP.NET MVC Il ne prend pas en charge l'approche pessimiste, nous devons donc travailler avec l'optimiste, pour cela nous devons fournir à nos structures des champs de date pour enregistrer la dernière fois qu'elle a été modifiée, afin que nous puissions savoir si la valeur a été modifiée après avoir obtenu l'enregistrement et avant de l'enregistrer, nous pouvons ainsi obtenir une alerte et ainsi décider d'écraser ou non ces valeurs.
Voyons un petit exemple de code de la façon dont nous pourrions valider ceci :
A la fin de ce tutoriel, nous en savons déjà un peu plus sur la concurrence dans les bases de données et comment travailler le problème dans ASP.NET MVC.
