Discussion :

[boby62423]

Bonjour,

Je souhaiterais verouiller un enregistrement dans une table afin que deux utilisateurs ne puissent pas faire de modifications concurentes.

Je m'explique en détail.

Imaginez une application windows forms avec un listing de clients.

Lorsqu'un utilisateur clique sur un client, sa fiche s'affiche. A ce moment la, même si rien n'a été modifié sur la fiche, je souhaiterais bloquer les autres utilisateurs afin qu'ils ne puissent pas ouvrir cette même fiche en même temps.

Si le pc du premier utilisateur plante, je souhaiterais que le verrou soit automatiquement verouillé.

En mysql, il existe un truc qui s'appelle get_lock() et qui aurait pu répondre à mon problème ici.
Donc si quelqu'un connait un mécanisme équivalent à get_lock, je suis preneur !

D'avance merci pour vos réponses

A+

[SQLpro]

Cette façon de faire est catastrophique et n'avait de seul intérêt que du temps des fichiers plats du style COBOL !!!
Nous en sommes aux bases de données en client/serveur qui verrouillent automatiquement en optimiste le temps de traitements.
Faire ce que vous voulez c'est revenir 30 ans en arrière sur la conception des SI.

Non seulement cela est catastrophique au plan des performances (ne prévoyez pas plus d'une dizaine d'utilisateur) mais n'a strictement aucun intérêt à quelque niveau que ce soit.

Essayez de me trouver un seul argument positif à cette façon de faire....
Je me pose d'ailleurs la question de ce que vous avez appris sur le plan scolaire en matière d'informatique ?

A +

[boby62423]

Je me suis sans doute mal exprimé en voulant parler de lock.

Au final, ce que je veux, c'est INTERDIRE l'ouverture d'une fiche client si un autre utilisateur l'a déjà ouverte.
Je me moque du fait que ça fait 70's. Les utilisateurs finaux sont un peu des boeufs et je préfère leur bloquer un accès préventivement, plutot que d'expliquer dans un beau message d'erreur que leurs modifs sont concurentes avec d'autres lorsqu'ils vont valider un truc sur la fiche client.

Je connais le principe des transactions, niveaux d'isolation et compagnie mais je veux même pas rentrer dans ce débat la.

Alors certes, je pourrais mettre un flag dans un champ de la table client qui serait positionné à true à l'ouverture puis remis à false à la fermeture mais c'est un peu dangereux en cas de plantage.

[SQLpro]

Quelque soit de façon de faire elle sera dangereuse. Comme c'est du fonctionnel, si vous persistez dans ce genre d'horreur alors faites le de manière fonctionnelle en utilisant justement une colonne (et non un champs, cela n'existe pas dans les SGBDR) pour ce faire.

Mélanger du fonctionnel et du technique (verrous interne) est à coup sûr le meilleur moyen de faire les pires conneries !

A +

[jero44]

Bonjour,
Est ce que vous travaillez avec des recordset(.net)? Si oui avez vous essayé les différents modes d'ouverture des recordset tel qu'exppliqué ici.

[boby62423]

Concrètement, vous préconisez quoi si on veut faire une belle application dans les règles de l'art ?

Je laisse 4 utilisateurs ouvrir une même fiche client et j'avertit du problème lorsqu'ils valident leurs modifications ?

Il y a effectivement des outils tout fait pour ça (linq to sql gère cela par exemple) mais moi perso j'ai un doute sur le fait que ce soit une bonne chose pour les utilisateurs. (J'ai besoin de votre avis la dessus.)

Merci

[agemis31]

Bonjour,

Ah le vieux débat locks pessismistes vs lock optimistes

Vous avez l'air d'avoir déjà choisi, il n'empêche que ce débat a été tranché depuis longtemps: pas de lock pessimiste.

Comme SQLPro l'a dit, ça remonte au temp des BDD fichiers, mais c'est surtout une question de probabilité et de loi de l'emmerdement maximum, pour vous, mais aussi pour vos utilisateurs.

Quelle est la probabilité pour que cela arrive ?

Si vous voulez gérer le verrouillage de façon pessimiste, vous allez à mon avis, au devant de nombreux problèmes.

Les utilisateurs finaux sont un peu des bœufs

Donc il vont rentrer en modification sur une fiche et la verrouiller pour rien...
Donc vous allez devoir gérer un timeout...
Donc les utilisateurs ne seront pas contents...
Si vous avez beaucoup d'utilisateurs, l'application sera lente, ça ne leur fera sans doute pas plaisir non plus...

C'est un peu le même débat que sur les conflits de mises à jour.
Certains font tout pour les éviter un édictant une règle simpliste du genre le premier/dernier gagne.
En général, ça ne marche pas trop bien.

@+

[lekunfry]

Cette façon de faire est catastrophique et n'avait de seul intérêt que du temps des fichiers plats du style COBOL !!!
Nous en sommes aux bases de données en client/serveur qui verrouillent automatiquement en optimiste le temps de traitements.
Faire ce que vous voulez c'est revenir 30 ans en arrière sur la conception des SI.

Non seulement cela est catastrophique au plan des performances (ne prévoyez pas plus d'une dizaine d'utilisateur) mais n'a strictement aucun intérêt à quelque niveau que ce soit.

Essayez de me trouver un seul argument positif à cette façon de faire....
Je me pose d'ailleurs la question de ce que vous avez appris sur le plan scolaire en matière d'informatique ?

A +

dire tout ceci sans propose d'alternative bref

[elsuket]

Bonjour,

La seule alternative c'est de confier cela à SQL Server, qui sait très bien le faire tout seul.
Rappelons que SQL est un langage déclaratif, et qu'en dehors de la recherche de performances, vous ne devez pas vous préoccuper de la façon dont le moteur de base de données gère le verrouillage, ou de la façon dont il accède aux données.

@++