Discussion :

[snake264]

Je vais essayé d'être le plus clair possible. Je développe une application en Java hébergé sur un serveur qui est appelé par un plugin installé dans un navigareur web. Sachant que le plugin peut être installé sur beaucoup plus d'un navigateur un problème de concurrence ce pose au niveau de l'application.

Cette application utilise des fichiers à chaque lancement d'une instance de l'application mais ces fichiers ne seront jamais modifiés donc toujours en lecture.
Malgré ça je voudrai que quand le fichier est déjà lu par une instance que les autres attendent que l'instance qui utilise le fichier se termine et ainsi de suite.

Une idée de comment je pourrai faire ça en Java ?

[NoClassDefFound]

J'avoue que je comprends mal le contexte
Pourquoi bloquer les flux en lecture sur les fichiers alors qu'ils ne sont pas susceptibles d'être modifiés ?
Si je pars de ton message, cela voudrais dire qu'il y a quelque part un bloc synchronisé pour la lecture des fichiers et un cache pour diminuer les problèmes de concurrence.

[snake264]

Pour le moment il n'y a absolument rien pour prévoir de la concurrence, c'est justement pour ça que je pose la question savoir si il y aura des problèmes et si oui comment les paliers. Et à l'avenir il y aura des fichiers modifiés mais pas pour le moment, donc autant prévoir la chose

[NRLinker]

je t'avoue j'ai pas vraiment compris aussi , vu que les fichiers sont on read only . Donc t'as pas besoin de les mettre thread safty pour éviter les problème de la concurrence puisque ya pas de concurrence vu que les données changent pas .Mais si tu veux vraiment le faire , bah mets la méthode qui li les fichiers en synchonized ou équivalent , comme ça y'aura qu'un accès à la fois .

[hwoarang]

Sans hésiter, je passerais par une base de données plutot que par un fichier. C'est fait pour gerer les problemes de concurrence et ca marche. Si tu aimes réinventer la roue, tu peux faire un service qui synchronisera les acces au fichier. Quelque soit le systeme que tu choisiras en utilisant seulement le filesystem, il y aura toujours des risques d'acces parallele.

[snake264]

je t'avoue j'ai pas vraiment compris aussi , vu que les fichiers sont on read only . Donc t'as pas besoin de les mettre thread safty pour éviter les problème de la concurrence puisque ya pas de concurrence vu que les données changent pas.

Exact pour le moment les fichiers sont en lecture seul mais ils vont bientôt devenir aussi modifiable.

Mais si tu veux vraiment le faire , bah mets la méthode qui li les fichiers en synchonized ou équivalent , comme ça y'aura qu'un accès à la fois .

Ok, donc si je met cette méthode en synchronized, toutes les instances accéderont au fichier chacun leur tour et seront mis en attente en attendant que l'instance qui utilise le fichier termine d'utiliser le fichier. C'est bien ça ?

Sans hésiter, je passerais par une base de données plutot que par un fichier. C'est fait pour gerer les problemes de concurrence et ca marche. Si tu aimes réinventer la roue, tu peux faire un service qui synchronisera les acces au fichier. Quelque soit le systeme que tu choisiras en utilisant seulement le filesystem, il y aura toujours des risques d'acces parallele.

Oui utiliser une base de donnée est une bonne idée mais ce n'est pas des fichiers de données mais des fichiers de configuration d'un framework, je n'ai donc pas trop le choix

[hwoarang]

Ok, donc si je met cette méthode en synchronized, toutes les instances accéderont au fichier chacun leur tour et seront mis en attente en attendant que l'instance qui utilise le fichier termine d'utiliser le fichier. C'est bien ça ?

Un bloc synchronized permet simplement de s'assurer que le bloc qu'il entoure n'est executé que pas 1 thread à la fois. Ca permettra de proteger ton fichier de config si et seulement si tous tes plugins se connectent sur l'application serveur pour lire le fichier de config et que celle-ci n'est lancée qu'une seule fois (en gros, cela revient à la solution de passer par un service que je proposais). Mais s'ils accedent au fichier par le filesystem, ca ne marche pas.

Oui utiliser une base de donnée est une bonne idée mais ce n'est pas des fichiers de données mais des fichiers de configuration d'un framework, je n'ai donc pas trop le choix

Ca parait etrange d'avoir à modifier à la volée un fichier de configuration de framework. En général, si le programme est amené à modifier des données de celui-ci, c'est que les données en question ne devraient pas y etre, mais plutot dans une base de données externe.

[snake264]

Un bloc synchronized permet simplement de s'assurer que le bloc qu'il entoure n'est executé que pas 1 thread à la fois. Ca permettra de proteger ton fichier de config si et seulement si tous tes plugins se connectent sur l'application serveur pour lire le fichier de config et que celle-ci n'est lancée qu'une seule fois (en gros, cela revient à la solution de passer par un service que je proposais). Mais s'ils accedent au fichier par le filesystem, ca ne marche pas.

Ok donc ça ne fonctionnera pas pour mon cas.

Ca parait etrange d'avoir à modifier à la volée un fichier de configuration de framework. En général, si le programme est amené à modifier des données de celui-ci, c'est que les données en question ne devraient pas y etre, mais plutot dans une base de données externe.

Dans mon cas, le framework que j'utilise change de configuration en fonction des demandes du plugin-in donc je passe par un service oui pour tout ce qui est données etc. mais le framework que j'utilise lui, ne peut pas se configurer avec une bdd.

La seule idée que j'aurai serait de configurer le framework directement dans le code sans passer par le fichier, mais ça rajoute beaucoup de code inutile et c'est un peu embêtant...

[NoClassDefFound]

A moins que tu ne puisses étendre/surcharger le gestionnaire de configuration de ton framework cela semble mal parti.
Par curiosité c'est un framework maison ?

[snake264]

Non c'est celui-là : http://gate.ac.uk/

Et ce framework peut entièrement être configurable via le code en fixant les valeurs soit même mais c'est très long et chiant car il y a énormément de paramètres de configurations. D'ou le fait de passer par des fichiers.

[hwoarang]

Par curiosité, tu peux donner des exemples de données du fichier de config susceptibles de changer ?

[snake264]

Une petite partie des possibilités de configuration de ce framework qui se configure avec plusieurs fichiers : http://gate.ac.uk/sale/tao/splitch2.html#x5-260002.4