Discussion :

[Nico_tournai]

Bonjour,

je commence un mini projet en python avec accés à une BDD postgre via le module psycopg2.
Je parviens a verrouiller des lignes d'une table grâce à un SELECT.. FOR UPDATE.
Là je suis content!

Par contre, si j'ouvre une 2e session et tente d'accéder aux memes lignes avec : SELECT.. FOR UPDATE. J'ai la session qui se fige tant que la premiere n'a pas fait son COMMIT (ce qui est normal).

Comment puis je tester si les lignes sont verrouillées au préalable sans faire attendre que la 1ere session se termine? Peut on savoir qui bloque les lignes? (l'ideal serait de faire apparaitre un message pour dire untel réserve les lignes..)
j'ai consulté divers forums où on parle de pg_locks mais j'ai très peu d'info dessus.

Pouvez vous m'aider?

Merci

[SQLpro]

Par principe ce n'est pas dans le code applicatif que l'on gère les verrous (d'ailleurs on ne devrait jamais avoir besoin de poser des verrous explicites). Le SGBDR le fait tout seul et il est certainement meilleur que vous à ce niveau car il est capable de prévoir la granularité (ligne, page, bloc, table...) comme le type (partagé, exclusif, schéma, intention, update...) de verrous de manière dynamique (en fonction du contexte et notamment de la concurrence et de la charge à un instant t)

Mais si vous voulez des performances catastrophiques et des deadlocks en pagaille, allez-y, amusez vous à tout verrouiller !

En revanche, vous pouvez gérer des transactions. Ca c'est la manière intelligente de développer des applications cohérentes.

Lisez ce que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlaz/techniques/
http://sqlpro.developpez.com/isolation-transaction/

A +

[estofilo]

On utilise pg_locks principalement pour trouver la source d'un problème en tant qu'administrateur de base de données.
Mais s'il s'agit de mettre en oeuvre une stratégie de coopération/exclusion entre sessions concurrentes, c'est probablement une mauvaise voie. Il faudrait préciser le besoin fonctionnel. Sinon il y a des fonctions de verrouillage coopératif dans postgresql (advisory locks), voir la doc à ce sujet.

[Nico_tournai]

Bonjour,

Admettons que plein d'intervenants sont amenés à modifier une fiche ( article par exemple car c'est le cas pour notre gestion de stock). Avec notre "SGBD" actuel, nous reservons la fiche, l'utilisateur fait ses modifs et on fait un update qui libere la fiche.
Personne d'autre ne doit pouvoir etre en modification si un utilisateur modifie la fiche en cours.
alors, Comment gerer cela en postgres? (verouiller un temps indefini)

peut être je dois procéder autrement et que je m'inspire trop du fonctionnement de notre "SGBD"..

les avis sont les bienvenus

merci

[estofilo]

Ce type de verrrouillage "pendant la saisie" doit idéalement être géré par l'applicatif.
Conceptuellement, une simple colonne dans une table qui dit "la fiche X est actuellement verrouillée par l'utilisateur Y" est suffisante comme technique de base.
Pour prendre le verrrou, un UPDATE sur la ligne de la fiche en question suivi d'un test pour savoir si la ligne a bien été mise à jour suffit à assurer l'exclusion mutuelle. Il faut ensuite faire un commit sans attendre.

Ce qu'il ne faut pas faire dans la plupart des SGBD, PostgreSQL inclus, c'est laisser des transactions ouvertes pendant que l'utilisateur saisit parce que ça bloque des ressources pour un temps indéterminé.

[SQLpro]

ça c'est du verrouillage pessimiste côté client. Le gros problème est : que va t-il se passer si l'utilisateur :
1) ne termine jamais sa session de travail (prend sa pause et tombe dans l'escalier en plien modif....)
2) sort de l'application sans passer par la bonne action
3) le PC fait un écran bleu
???

Dans tous les cas gérer les verrous manuellement en mode pessimiste à l'heure, des SGBDR de type C/S reste une hérésie. Il faut changer votre manière de faire et abandonner vos vieilles habitudes

Sachez d'autant plus que dans un curseur, (les datagrid "live" reposent sur des curseurs) cette gestion est automatisée.. La question est :
es-te vous en mode client lourd ou léger ?

A +

[Nico_tournai]

Bonjour,


prenons le cas suivant :
- un utilisateur consulte sur une fenetre une fiche 'article' (simple select) avec differentes infos (poids=10 , volume=2 , couleur=bleu)
- un autre utilisateur consulte la même fiche à l'ecran
- le premier saisie un poids de 15 et fait un update (de tout) avec ses données de l'ecran -> (poids=15, volume=2, couleur=bleu)
- l'autre utilisateur (il voit toujours poids=10..) saisie volume=5 et fait un update avec ses données de l'ecran -> on revient à poids=10

C'est sans doute un cas d'ecole mais je vois pas trop comment gérer le truc.

Notre système est fait avec un langage limité (proche du basic et je suis l'un de rares à connaitre le langage spécifique où on doit faire à chaque fois des pirouettes pour s'en sortir..) et python semble palier aux problèmes par sa facilité notamment.

je travaille pour une société import/export où il y a différents services (logistique, transport, ...).
Tout le temps, les utilisateurs peuvent modifier une fiche article (nous avons des tas d'infos renseignées pour une fiche article, mais y a d'autres tables de ce genre) grâce à un système de reservation/libération avec un vieux 'SGBD'. Et si la session de l'utilisateur plante, ces fiches réservées sont libérées.
Il faut vraiment que personne ne puisse modifier une fiche si un autre en fait la modification PENDANT UN CERTAIN TEMPS (le temps que l'autre renseigne les infos) mais on peut y acceder en read.

J'avais pensé à une table de reservation (untel reserve telle fiche) mais qu'advient il si une session plante?
Ce sont des interrogations pour une hypothétique migration de notre système.

[bhamp0]

Solution que j'ai déjà implémentée et qui fonctionne correctement :
* on ne locke personne, car ça crée des problèmes de deadlock après ...
* on ajoute sur toutes les tables modifiables par IHM un champ de "date de dernière mise à jour"
* on passe la valeur de la dernière mise à jour sur les pages de modification
* au moment d'un update, on regarde si la date de dernière modification stockée en base correspond à celle passée en paramètre ; si oui, on fait l'update (notamment la date de màj) et c'est bon ; si non, on renvoie un warning à l'utilisateur en lui indiquant que la fiche a été mise à jour (éventuellement, on peut même lui montrer les différences de valeurs au niveau de chaque champ : nouvelle valeur stockée VS valeur saisie)

[estofilo]

- l'autre utilisateur (il voit toujours poids=10..) saisie volume=5 et fait un update avec ses données de l'ecran -> on revient à poids=10

Il faut peut-être que l'application actualise la fiche avant d'entrer en mode modification. Mais en quoi est-ce que ce problème ne se pose pas déjà avec le SGBD actuel? C'est un problème fonctionnel, pas technique.