Bonjour,

N'étant pas familière avec les threads, je préfère vous poser la question directement.

Je crée une application java, une interface graphique en fait, pour accéder à une base de donnée psql.
Cette interface pourra consulter/modifier cette base de donnée.
Cette application pourra être ouverte par plusieurs utilisateurs qui pourront donc accéder aux mêmes données.

Un des problèmes de synchronisation auquel j'ai pensé c'est la modification des données. Dans mon schema relationnel, j'ai une classe stagiaire que l'on peut apparenter à une classe membres. Les utilisateurs de l'application pourront donc modifier des informations sur les stagiaires. Je dois donc bloquer la consultation d'un stagiaire si celui-ci est en cours de modification.

Est ce que ce sont les threads qui peuvent m'aider à résoudre ce problème de concurrence ou cela n'a rien à voir ?

Rien à voir avec les threads.

Si la modification d'un stagiaire tient en une seule requête il n'y a aucun problème, si elle tient en plusieurs requêtes, utilise une transaction.

Citation : Zazou

Je dois donc bloquer la consultation d'un stagiaire si celui-ci est en cours de modification.

Dans le modèle objet ou la DB? si c'est la DB, suffit de mettre le niveau d'isolation à la valeur adaptée.
Si c'est pour la modèle et que plusieurs thread accèdent aux données, suffit de synchronizer les parties sensibles.

Ça ne suffira pas. Soit les 3 actions suivantes :

1. Consultation du stagiaire (select + affichage) par A
2. Modification du stagiaire (update) par A
3. Consultation du stagiaire par B

Il peut très bien se passer : 1-2-3 et il n'y a pas de problème. Mais quid des actions si elles sont dans l'ordre 1-3-4 ?
A accède aux données, B accèdes aux données, A modifie les données --> B ne voit plus les bonnes données puisqu'elles sont mise à jour entre temps.

Ma question est donc, comment faire pour bloquer l'accès aux données d'un stagiaire si elles sont déjà lues par un autre ?


@shakkal, bah je ne sais pas justement à quel niveau je dois vérifier ces problèmes d'accès, d'où la question.

Attends tu ne peux pas bloquer tes clients indéfiniment en supposant qu'une modification va bientôt avoir lieu.

Pourtant je le dois. Si un utilisateur a ouvert la fiche d'un stagiaire, personne d'autre ne doit y avoir accès. C'est tout.

Salut Zazou.
En fait dans ton exemple il n'y a pas de vrai problème de synchronisation, tant que B ne réécrit pas les données qu'il a lu. Le seul problème c'est que les données de B ne sont pas à jour mais ça aurait également été le cas si B l'ordre avait été 3 - 1 - 2.
Si le but est que B ait toujours des données à jour, un patron de conception observateur peut être utilisé (B s'inscrit pour être prévenu à chaque modification).
Sinon si c'est un vrai problème de synchro, je vois plusieurs solutions :
- Verrou sur les ressources, B ne peut pas accéder aux ressources tant que A est en train de les lire ou modifier. Si on peut différencier les deux cas (lecture et écriture) alors une synchro sur un modèle lecteur écrivain serait intéressant (plusieurs lectures possibles en même temps).
- Sinon une solution optimiste, pas de verrou mais si jamais les données ont été modifiées entre le moment où B a accédé aux données et le moment où il veut écrire ses modifications, il reçoit une erreur. Cette solution peut être coupler aux patern observer pour que B soit prévenu dès que les données sont modifiées par A.

C'est bien le premier cas de figure qui m'intéresse si c'est possible d'y remédier.
L'idée étant soit qu'à la consultation on ait toujours des données justes (provenant de la base de donnée) soit qu'on ne puisse y accéder si le stagiaire est déjà "pris" par un utilisateur.
Je vais donc d'abord voir du côté du design pattern Observer comme tu le préconises. Et si je n'y arrive pas et bah ma foi j'suis dans la merde.

Oui, donc pour préciser un peu, là on ne cherche pas à faire un mutex pour des threads du programme mais pour les utilisateurs (le mutex sur le code doit en gros se limiter au moment ou l'on modifie une variable pour indiquer quand un stagiaire est "pris" ou "libéré" et les moments ou on regarde cette variable). Donc quand le deuxième utilisateur arrive alors qu'un autre est prend déjà l'utilisateur il faut qu'il ait un message qui lui indique la situation. Il faudrait alors qu'il lui soit proposé soit d'abandonner soit de patienter auquel cas il devra être prevenu dès que le stagiaire est libéré par l'autre utilisateur (sauf s'ils sont plusieurs à attendre pour le même stagiaire).
Il faut aussi penser à mettre un délai maximal au bout duquel un stagiaire est libéré (on peut prévenir l'utilisateur avant). Ceci afin d'éviter que si un utilisateur oublie de fermer l'application ou qu'il y a un crash l'état soit bloqué perpétuellement.

Bonjour,

Je suis en train d'essayer de mettre en place le patron de conception observer. Mais je me posais une question. Dans mon application, quelle classe est Observable et quelle classe serait Observateur ?

En fait là c'est peut être un peu compliqué...
Si je comprends bien il y a plusieurs application stand alone que accède à la même base de donnée et les différentes applications java ne communique pas entre elles directement ?
Leur seul moyen d'échanger des informations est de passé par la base de donnée ?
Du coup il faut modifier la structure de la bd pour ajouter une variable dans une table de la bd pour signaler qu'un stagiaire est en train d'être modifié (avec une date).
Mais comme ça ne doit pas être possible d'être prévenu par la base de donnée quand cette variable est modifié (ie quans le salarié est "libéré"), il doit falloir que l'application qui est en attente de la libération d'un stagiaire pull régulièrement la bd (c'est un peu moche comme principe).

Sinon pour répondre sur le principe l'observable pourrait être la classe représentant le "stagiaire" en train d'être modifié (ou le mutex lié à ce salarié) et les observateurs seraient toutes les interfaces qui affichent les données liées à ce stagiaire (ou qui attendent sa libération)

Bon finalement j'ai trouvé plus simple, du moins en théorie... Une variable static contenant les ID des stagiaires inaccessibles. Changer de panel, fermer l'application provoquant le remove de l'id qui était lu.

Mais ta variable static n'est accessible/partagée que dans la JVM de ton programme.
Si tu as une autre instance de ton programme dans une autre JVM (et donc a fortiori sur un autre PC) ça ne servira à rien, ils auront chacun leur liste.
Mais bon je n'ai peut être pas compris le besoin.

Hum ah oui, je n'avais pas pensé à ça... Pfff ça m'énerve... J'ai bien compris le principe du pattern Observer mais je ne vois absolument pas comment le mettre en place dans mon application.

tu devrais peut être plutôt partir sur une application client serveur ou tu pourrait avoir tout d'abord un vrai contrôle des données entrantes via le controlleur et un retour facilité vers les clients en utilisant observer.

Ca éviterait aussi d'exposer directement la DB aux clients, normalement ça se fait pas.

Bref, un petit mvc devrait régler tout ça.

Je travaille déjà en MVC en tout cas un dérivé de MVC. Il est pas parfait mais bon...
J'essaie de me débrouiller comme je peux parce que mon DUT on a pas tellement vu cet aspect-là de la programmation concernant les design pattern. Pour ne pas dire, pas du tout.

Ça va qu'à la base j'suis plus spécialiste de la programmation PHP et dont je connaissais les grands principes du MVC que j'essaie tant bien que mal d'appliquer pour mon application java mais ce n'est pas toujours évident.

Et je ne parle même pas de mes connaissances en thread qui sont pour le moins quasi inexistente.

Donc faire un client/serveur ... Comment dire, je ne sais pas faire pour l'instant

Quels seraient les avantages de faire un serveur dans mon cas ? Sachant que je ne veux que pouvoir empêcher d'accéder à un stagiaire si celui-ci est déjà accédé par un autre utilisateur. Et que veux-tu dire par "exposer la DB aux clients" ?

l'avantage du serveur:
-un controlleur centralisé, pas de risque que les clients modifiés envoient des données non permises.
-DB pas exposée: les client ne connaissent pas les identifiants et même si c'était le cas, n'on pas accès vu que l'accès sera uniquement localhot.
-Avec le controler c'est facile de prévenir les clients voulant accéder aux données que quelqu'un est dessus en écriture.
-divers autres trucs, si quelqu'un veut compléter...

Oui en passant à une architecture type j2ee/web je rajouterai :
* Gestion et déploiement des nouvelles versions. Une seule machine à mettre à jour, pas de parc non homogène (si on ne compte pas les browsers web).
* Pas d'installation client (ils ont juste un navigateur web).

Sauf que je ne dois pas faire de web, je dois faire uniquement du java et que du java.

Bien au contraire, les clients DOIVENT connaître les identifiants de la base de donnée.

Ce ne sont pas des clients comme les autres dans mon cas. Je suis stagiaire dans une association et je leur crée un logiciel de gestion. Quand je partirai, d'une je donnerai toutes les sources, de deux ils devront pouvoir configurer le serveur psql et donc le logiciel eux-même.

Je me posais une question. Dans mon association, il y a un serveur donc et un dossier partagé sur tous les postes.
Si je place le .jar sur ce serveur, et que l'on exécute sur 2 postes différents, est ce que les 2 postes peuvent avoir accès au même instance static ?
ça m'arrangerait grandement si c'était le cas... ça m'éviterai de coder tout un bordel.