Discussion :

[Pierre59]

Bonjour,

Mon problème et simple (et récurent) mais je ne parviens pas à le résoudre "simplement".

Voila, j'ai un tableau (réalisé en Java-Web relié à une BDD SQl Server) représentant des demandes.
Le fait de cliquer sur une ligne de ce tableau signifie "Je vais traiter la demande": Cela ouvre une fenêtre avec le détail de cette demande et l'utilsateur peut notifier "en cours" ou "clôturer" ainsi que l'action effectuée.
Existe t'il un moyen (sans passer par une table dédiée) de:
- L'utilisteur 1 clique sur la ligne => cela verrouille l'enregistrement en lecture/ecriture.
- Pendant ce temps l'utilisateur 2 essaie également d'accéder aun même enregsitrement => Il se prend un message "enregistrement en cours de maj..."

Comment réaliser cela simplement ??

Merci!
A+
Pierre

[cubitus91]

Salut,



http://sql.developpez.com/sgbdr/

Cdt

[Pierre59]

Salut,



http://sql.developpez.com/sgbdr/

Cdt

J'ai lu ce tutoriel et connaissait les méthode de vérouillage.
Mais concrètement ?
La transaction ne peut être faite en une seule fois :
L'utilisteur clique, je fait un select pour instancier mon objet et là quoi ?? Il existe une instruction LOCK ?
Et cas échant un UNLOCK à la fermeture de fenêtre ?

[rudib]

Bonjour,

La mauvaise méthode est de maintenir une transaction, la bonne est de gérer cela à la main dans une table de lock ou avec une colonne supplémentaire de ta table.

[Pierre59]

Avant tout merci pour votre réponse.
OK je vais créer une table annexe qui va stocker l'id de l'enregistrement + l'id de la personne qui verrouille. Cela me permettra de mettre un message :
Cet enregistrement est vérouillé par untel.

Je vais de plus prévoir une proc stockée déclenchée la nuit qui tonque la table des vérrous.

Pourriez-vous néanmois m'expliquer la méthode pour maintenir une transaction ?

PS: Je trouve vachement décevant de SQL-Server qu'on ne peut pas le faire en natif.

[rudib]

PS: Je trouve vachement décevant de SQL-Server qu'on ne peut pas le faire en natif.

C'est une réaction assez courante. La mission du SGBD Client Serveur est de stocker et mettre à disposition des données en garantissant leur intégrité et leur cohérence. La logique de verrouillage au niveau du client ne les concerne pas.
En réalité, les fonctionnalités que vous demandez existent bel et bien dans SQL Server. Il vous suffit de vous mettre en niveau d'isolation REPEATABLE READ et de créer une transaction explicite, que vous ne commiterez qu'après la fin de vos manipulations. Vous aurez des attentes sur des verrous chez les autres utilisateurs, et des timeouts, et non pas des messages clairs. Vous diminuerez très fortement la concurrence d'accès à vos données, et vous prendrez le risque qu'un utilisateur qui abandonne son ordinateur avec une fenêtre de votre programme ouverte, pour prendre des vacances de quinze jours, ne bloque tout le monde.

Pour implémenter la solution manuellement :
- créez une table qui contient l'identifiant de la table et de la ligne que vous voulez bloquer, ainsi que le login, le SPID, la date... tout ce dont vous avez besoin.
- faites une procédure stockée standard de verrouillage et déverrouillage, une autre de vérification du verrou, qui retourne un message (en RAISERROR par exemple) clair lorsque la ligne est verrouillée.
- Tournez régulièrement un job qui vérifie que le SPID est toujours actif, ou que le SPID est toujours sur le même login (pour traiter le cas de réattribution du SPID). S'il est inactif ou qu'un délai est dépassé, libérez le verrou.