SYNCHRONISATION AVEC UN FICHIER PROPERTIES
Twinuts
Messages postés
5375
Date d'inscription
dimanche 4 mai 2003
Statut
Modérateur
Dernière intervention
14 juin 2023
-
5 déc. 2006 à 16:32
codefalse Messages postés 1123 Date d'inscription mardi 8 janvier 2002 Statut Modérateur Dernière intervention 21 avril 2009 - 19 déc. 2006 à 22:11
codefalse Messages postés 1123 Date d'inscription mardi 8 janvier 2002 Statut Modérateur Dernière intervention 21 avril 2009 - 19 déc. 2006 à 22:11
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/40591-synchronisation-avec-un-fichier-properties
https://codes-sources.commentcamarche.net/source/40591-synchronisation-avec-un-fichier-properties
19 déc. 2006 à 22:11
19 déc. 2006 à 20:08
en gros cela veut dire simplement qu'a un instant donné tu es le seul à pouvoir accéder au fichier
19 déc. 2006 à 18:31
Je connais les termes de synchronisation mais pas avec un fichier ?!
Pourriez vous m'expliquer s'il vous plait ?
merci :)
6 déc. 2006 à 23:45
"Si mon constructeur est en private" <- milles excuses je viens seulement de le voir caché entre deux commentaires :D si le constructeur est private comme c'est le cas et que l'instance interne est static alors pas de risque le singleton fonctionne :)
6 déc. 2006 à 21:24
ConfigManager myconfigs = new ConfigManager();
Sauf au sein de la la classe ConfigManager. Du moins mon Eclipse ne l'autorise pas donc il y a certainement erreur de compilation (au pire je testerai une compilation en console).
Si je fait :
private ConfigManager mesConfig1 = ConfigManager.getInstance();
private ConfigManager mesConfig2 = ConfigManager.getInstance();
Les 2 objets devrait pointer vers l'objet instance ?
Je vais faire des tests (il ya plus de chances que tu aie raison que le contraire :) )
Super pour le shutdown, je pense que je vais :
- faire hérité Thread à ConfigManager
- ajouter le blocage et addShuttdownhook(this) dans la methode synchronise
- supprimer le blocage et removeShuttdownhook(this) dans la methode desynchronise
- copier le contenue de la methode desynchronise dans la methode run (sauf removeShuttdownhook(this)...)
C'est ce qui me parait être le plus simple.
Ce week-end celà devrait être testé au niveau du singleton et le shutdown réalisé.
Un grand merci
6 déc. 2006 à 19:52
- cela joue si tu utilise le constructeur public sans passer par le getInstance
"j'hesite encore à l'ajouter, en cas d'arret brutal du programme, la methode desynchronise() "
- enfait le lock prendra fin en cas d'arret de l'appli sinon tu peux le faire proprement et utiliser le shuttdownhook de Runtime ref(pour un exemple) : http://www.techmag.biz/java_app_shutdown_hook
"si un programme quelconque utilise et met à jour le fichier properties sans passer par l'api, le lock n'a plus d'interet"
- si par ce qu'il ne pourra ni lire ou modifier le fichier vu que dans mon exemple j'ouvre le fichier en rw soit read & write et le lock le vérouille sur le mode d'ouverture soit read write
6 déc. 2006 à 18:31
Le lock est prévu par la suite, je ne l'est pas noté dans les commentaires final de la source pour plusieurs raisons :
- j'hesite encore à l'ajouter, en cas d'arret brutal du programme, la methode desynchronise() ne sera pas apelé et le deblocage du fichier ne se fera pas, à moins que je me trompe...
- je n'est jamais utilisé de fichier lock et je ne voulais pas noté une possible mise a jour sans être sûre d'en être capable. Ton bout de code devrait m'aider, merci
- si un programme quelconque utilise et met à jour le fichier properties sans passer par l'api, le lock n'a plus d'interet.
Je ne suis pas un pro de java et comme je l'est dis, j'ai jamais utilisé le blocage de fichier et il se peut que je me suis complètement trompé dans mes raisons.
Je ne le prend pas comme une critique, c'est bien le but de ce site, partager ses connaissances/idées ;)
5 déc. 2006 à 21:14
concernant ton code il y a des choses que je ne comprend pas tu dis que tu fais de la synchronisation ...... mai c'est faux, je m'explique :
tu déclares la variable private boolean synchronise = false; hors il y à un truc qui ne cole pas si tu fais :
private ConfigManager mesConfig1 = ConfigManager.getInstance();
private ConfigManager mesConfig2 = ConfigManager.getInstance();
ici chacun à sa synchro ce qui n'est pas vraiment propre .... donc 2 solutions soit tu mets synchronise en static soit tu mets le constructeur de ConfigManager en private comme cela déjà tu commenceras à avoir un début de synchronisation...
ensuite autre chose tu ne lock pas le fichier ce qui est assez dommage vu qu'une application '1' peut modifier le fichier qu'utilise l'application 'n'... pourquoi ne pas lock le fichier ?
tu peux le faire avec :
private boolean locked = true;
private RandomAccessFile raLockFile = null;
....
try {
File lockedFile = new File(fileName);
raLockFile = new RandomAccessFile(lockedFile, "rw");
if(raLockFile.getChannel().tryLock() == null)
locked = false;
else
locked = true;
} catch (Exception e) { }
....
public boolean isLocked(){
return locked;
}
et pour le déloquer
raLockFile.getChannel().close();
bref c'est pas vraiment une critique mais plus une pitite remarque qui pourrait rendre ta classe réellement synchronisé par une application voir même plusieurs applications
5 déc. 2006 à 18:19
5 déc. 2006 à 17:45
5 déc. 2006 à 16:32
pourrais tu stp ne pas mettre les fichiers java dans un zip c'est super lourd de devoir télécherger le zip pour visualiser une source...