Discussion :

[JeromeBcx]

Bonjour,

Je commence par poser le contexte...
J'ai une application répartie sur plusieurs postes et une base de donnée PostGreSQL qui regroupe les données de l'application.
L'architecture de l'application se présente ainsi :
Un ou plusieurs "clients" vont servir à paramétrer un job. Les données sont déposées sur la BDD. Différents modules de calculs répartis sur le réseau vont "écouter" la BDD et vérifier si ils peuvent éxécuter la totalité ou une partie d'un job.

Le système est au stade de l'architecture et mes connaissances en Base de données sont assez pauvres !!!

Ma question se pose sur la gestion d'éxécution des modules. En effet, si rien n'est prévu, un module va lire dans la table si un job est à éxécuter en (par exemple) venant lire une variable et vérifier dans un autre champ si le job n'est pas déjà en cours.
Mais comment vérifier si un autre module n'est pas déjà en train de réaliser la même opération ?
y a t'il un mécanisme dans la base pour éviter à plusieurs modules de lire un même champ en même temps ? Je comparerais cela au mécanisme de Mutex sur une instruction.

En espérant avoir été assez clair et en vous remerçiant par avance pour les réponses,

Cdt.

[scheu]

C'est un problème classique des bases de données (verrous de tables et accès concurrents)
Tu peux par exemple utiliser la commande LOCK pour verrouiller une table en lecture et/ou écriture selon les besoins

[JeromeBcx]

Merci pour la réponse à question "classique"... je sais mes compétences dans le domaine sont vraiment pauvres !!!

Après avoir lu la description de la fonction LOCK, une ligne me chagrine !!!

Il n'y a pas de commande UNLOCK TABLE ; les verrous sont systématiquement relâchés à la fin de la transaction

CE point m'inquiète quelque peut... En effet, dans la procédure qui concerne mon application, un module va regarder si un job est à traiter, il va donc lire une donnée sur une table, puis il va affecter cette donnée à un autre état (par exemple "en cours d'évaluation"). Il va vérifier s'il peut effectuer le calcul : si oui, il réaffecte la valeur à "en cours de traitement", sinon, il réinitialise la valeur à "job en attente de traitement".

Est-ce qu'il n'y a pas de risque de conflit entre la premier lecture et la première écriture ?

Il n'y a pas possibilité de faire quelque chose du genre :

- J'essaie de locker la donnée : oui continue, non je rééssaye
switch "donnée"
case : "en attente de traitement"

Je vérifie si je peux effectuer le job

si oui, je change donnée en "en cours de traitement"
Je délock

sinon je délock

case : "en cours de traitement"

Je délock

Cette question est peut-être aussi bête que la première, mais de ces questions basiques dépendent tout le reste de mon application.

En vous remerçiant.

[scheu]

Je ne suis pas sûr d'avoir bien compris ton problème
Si un module locke une table pour changer le status d'un job, les autres sessions concurrentes voulant accéder à cette table seront "en attente" de la libération du verrou (c'est le principe d'un lock) donc ne te rendront pas la main, et quand ton premier module va changer le status du job et commiter, les autres modules vont pouvoir lire la table et lire uniquement le nouveau status du job, donc je ne vois pas bien où il peut avoir un conflit

[JeromeBcx]

Merci pour tout scheu,

J'ai enfin réussi à avoir l'info que j'avais besoin. En effet, pour moi (la manière dont j'avais compris l'aide de LOCK), la procédure était la suivante :
- je veux lire une donnée,
- je lock la table
- je récupère la valeur,
- le unlock est réalisé automatiquement après...
Donc vu ma compréhension, je me retrouvais bloqué.

Mais je sais maintenant qu'il est apparement possible de locker et de réaliser plusieurs instruction à la suite, ainsi rester en lock tant que le module n'a pas pris sa décision.

Je suis désolé, je me sens un peu bête à poser ce genre de questions, mais les bases de données, je ne connais vraiment que les grandes lignes (je devrais dire les autoroutes)-> mais bon c en posant des questions que l'on devient un (j'ai du chemin dans ce domaine...)

Je vais avoir le soutien de gens compétants dans pas longtemps, mais en attendant, je dois réaliser l'archi de la solution tout seul !!!

Si personne ne voit d'objection, je passe en RESOLU

Cdt et merci encore.