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 +