Discussion :

[yellowsub122]

Bonsoir.

Je suis un vrai débutant.
J'essaye de faire pour le fun une application ASP.Net (VB.Net) qui met à jour des données dans une base.
En gros, j'ai une base et un formulaire. A travers ce formulaire, je mets à jour une table.

Ma question est la suivante: les applications "web" étant des applications en mode "déconnecté", comment m'assurer que l'enregistrement sur lequel un utilisateur travaille ne soit pas accessible par un autre utilisateur ?

Je voudrais éviter que 2 utilisateurs puissent accéder au même enregistrement pour mettre à jour !

Merci pour votre aide.

[Graffito]

Il y a le choix entre solution "optimiste" et solution "pessimiste".

• La solution pessimiste consiste à mettre un verrou sur l'enregistrement dès qu'on veut entrer en edition. Inconvénients : si l'édition est stoppée, l'enregstriment ne se dévérouillera qu'au bout d'un time-out, et il faut vérifier lors de la mise à jour que le verrou est toujours en place.
• La solution optimiste consiste à s'assurer lors de la mise à jour que l'enregistrement modifié correspond à celui qui a été lu avant édition.

[yellowsub122]

Il y a le choix entre solution "optimiste" et solution "pessimiste".

• La solution pessimiste consiste à mettre un verrou sur l'enregistrement dès qu'on veut entrer en edition. Inconvénients : si l'édition est stoppée, l'enregstriment ne se dévérouillera qu'au bout d'un time-out, et il faut vérifier lors de la mise à jour que le verrou est toujours en place.
• La solution optimiste consiste à s'assurer lors de la mise à jour que l'enregistrement modifié correspond à celui qui a été lu avant édition.

Bonjour.

je me suis levé du bon pied ce matin aussi vais-je essayer de partir sur la solution optimiste.
Si j'ai bien compris, il "suffirait" de s'assurer de mettre un critère dans la requête "update" soit unique n'est-ce pas ? (update table_toto set colonne_titi='...' where critère unique).

Merci.

[cybermaxs]

Bonjour.

je me suis levé du bon pied ce matin aussi vais-je essayer de partir sur la solution optimiste.
Si j'ai bien compris, il "suffirait" de s'assurer de mettre un critère dans la requête "update" soit unique n'est-ce pas ? (update table_toto set colonne_titi='...' where critère unique).

Merci.

Oui. Dans la pratique, on ajoute aussi souvent une colonne dédiée de type timestamp ou autre. Lors du chargement de ligne ou de l'objet, tu récupère cette valeur avec le reste. Lors de l'update tu ajoutes une condition dans le where pour mettre à jour que si le timestamp est égal. (ne pas oublier de la mettre à jour aussi). Ensuite en analysant le nombre de requêtes affectées, tu peux dire si tes données étaient à jour ou pas.

[Graffito]

il "suffirait" de s'assurer de mettre un critère dans la requête "update" soit unique n'est-ce pas ? (update table_toto set colonne_titi='...' where critère unique).

Perso, je vérifie l'égalité de tous les champs lus.
Sinon, lors des update, on peut toujours utiliser une transaction pour mettre dans l'enregistrement un ticket unique chaque fois qu'on écrit dedans. Il suffit alors de tester que la valeur du ticket n'a pas changé.

[cybermaxs]

Perso, je vérifie l'égalité de tous les champs lus.
Sinon, lors des update, on peut toujours utiliser une transaction pour mettre dans l'enregistrement un ticket unique chaque fois qu'on écrit dedans. Il suffit alors de tester que la valeur du ticket n'a pas changé.

d'où l'idée du timestamp ... Car pour tes tables avec 20 colonnes, ça devient barbant à faire.

[yellowsub122]

Merci messieurs pour votre contribution.

En résumé, si j'ai bien compris, il faut créer une nouvelle colonne dans ma table.
Lors du chargement de l'enregistrement dans mon formulaire, je mets un flag genre "occupé par Titi à 10:34:45 le 10022010" (un truc unique quoi) dans cette colonne.
Lors de l'update, je me sers de ce flag unique qui m'assure que j'udpdate bien le bon enregistrement.
Ce flag m'assure aussi que personne d'autre peut prendre l'enregistrement.

Si j'ai faux, alors n'hésitez pas à me le signaler. Entre temps, je clos ce sujet.

Merci encore.

[Graffito]

Car pour tes tables avec 20 colonnes, ça devient barbant à faire.

En effet, mais j'ai créé un générateur automatique de Command Fill, Update/Insert/Delete à partir d'une table quelconque (enfin, je me limite à Access, Oracle et MySQl).

[Graffito]

Lors du chargement de l'enregistrement dans mon formulaire, je mets un flag genre "occupé par Titi à 10:34:45 le 10022010" (un truc unique quoi) dans cette colonne.

Non, le flag doit être écrit lors de la création ou l'update.

Lors de l'update, je me sers de ce flag unique qui m'assure que j'udpdate bien le bon enregistrement.
Ce flag m'assure aussi que personne d'autre peut prendre l'enregistrement.

Non, on compare le flag lu lors du chargement à celui qui est dans l'enregistrement lors de la transaction d'update.
L'identité des 2 valeurs t'assure que personne d'autre n'a modifié l'enregistrement entre la lecture et la modification.

[yellowsub122]

Non, le flag doit être écrit lors de la création ou l'update.

Non, on compare le flag lu lors du chargement à celui qui est dans l'enregistrement lors de la transaction d'update.

Pourquoi seulement lors de l'update ?
Si aussi tard, cela signifie qu'entre le chargement de la page (avec les données issues de la base) et l'update, un autre utilisateur peut prendre l'enregistrement en question non ?

L'identité des 2 valeurs t'assure que personne d'autre n'a modifié l'enregistrement entre la lecture et la modification.

ok mais là, tu ne fais que contrôler si personne d'autre n'a changé ton enregistrement avant toi mais ce que je veux, c'est empêcher toute autre personne de prendre l'enregistrement que j'ai pris avant que je le libère.

[Graffito]

aussi vais-je essayer de partir sur la solution optimiste.
...
Je voudrais éviter que 2 utilisateurs puissent accéder au même enregistrement pour mettre à jour !

C'est incompatible, "optimiste" veut dire que :
La probabilité que 2 utilisateurs modifient simultanément le même enregistrement est si faible qu'on accepte que la saisie de la modification puisse échouer au moment où on fait l'Update dans la base de donnée.

Si cela ne convient pas, c'est la solution "pessimiste" qu'il faut choisir!

[yellowsub122]

Bon.

je clos ce sujet.

je pensais qu'il y aurait une solution "simple" et "rapide".
Elle existe sans doute mais comme "simple" et "rapide" sont deux notions subjectives, et que je ne suis pas bon du tout (débutant de chez débutant), je dois considérer qu'elle n'existe pas pour moi.
Hihihhiih.
je continue de chercher.


Merci en tout cas.