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.

@+

[SQLpro]

Quel est l'importance que l'un écrase le modifs de l'autre ?
En gros celui qui dort devant son écran emmerde tout le monde.
Imaginez ce qui se passerait si c'était le cas pour un site de vente comme Amazon !!!!
Il suffirait d'oublier de fermer une page web pour le que dernier best seller à la mode ne puisse plus être acheté !!!!!
Impensable.

tant qu'a faire, est-ce que c'est bien l'utilisateur qui dort dans son coin avec la fiche ouverte que vous voulez à tout prix protéger ou ne serait-il pas plus intelligent que la priorité soit accordée au PDG ?
Dans ce cas, le PDG ne devrai-il pas s'il le désire être prioritaire devant tout autre utilisateur et même passer outre une fiche déjà ouverte par madame tartemuche ???

Voyez à quel point ce mode est stupide et a depuis des décennies été abandonné !

A +

[boby62423]

Oui je comprend mais j'ai oublié de vous préciser quelque chose:

J'ai fait une appli ultra simple avec des fenetres modales, c'est à dire que l'on ouvre les fiches clients qu'une par une...

[boby62423]

Prenons un autre exemple:

J'ai une table qui contient la liste des utilisateurs (avec leur login/pass)

Quel est le meilleur moyen pour faire en sorte qu'un utilisateur ne peut être connecté qu'une seule fois a un instant donné ?

[agemis31]

Bonsoir,

Je ne sais pas si ce sont les meilleures solutions, mais voici ce qui me semble envisageable.

J'ai fait une appli ultra simple avec des fenetres modales

Si l'utilisateur se connecte toujours du même poste de travail, pourquoi pas un mutex ?

Côté BDD:

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

Pourquoi ?

Pourquoi pas une colonne bConnected ?

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.

Mécanismes de reset:

• Manuel
• Timeout/message de vie

@+

[boby62423]

Merci pour ta réponse mais le principe du flag avec le timeout me parait un peu old fassion non ?

[FMJ]

Je ne voudrais pas en rajouter mais c'est plutôt de s'obstiner à ne pas vouloir utiliser un lock optimistic qui pourrait paraître un brin "old fashioned"

Et si tu as si peur que cela qu'un ensemble de lignes soit modifiées par un autre utilisateur, tu n'as qu'à faire une routine qui vérifie périodiquement que tes enregistrements non pas été modifiés ou sinon un flag est affiché dans l'interface utilisateur pour l'avertir qu'elles ont été modifiées.

[boby62423]

Ok vous m'avez (presque) convaincu pour le lock optimistic.

On est bien d'accord que ce mécanisme conssiste à autoriser tout le monde à faire des modifs en même temps et de traiter les choses au cas par cas en regardant db.ConflictChanges avant de faire un db.submitChanges() ?

[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.

@++