Salut,
 
J'ai un souci sur mon projet: je dois empêcher que deux instances d'un programme s'exécutent en parallèle à cause d'un problème de collision sur une ressource partagée. Autre contrainte: les 2 instances du programme s'exécutent dans 2 JVMs distinctes (sinon ce serait trop facile)... Comment puis-je m'assurer lorsque mon programme se lance qu'une autre instance n'est pas déjà démarrée ???
 
J'avais pensé à créer au lancement de mon prog un fichier sur le disque qui servirait de "flag" afin de passer l'information entre les JVMs. Si le fichier existe, une instance est en mémoire sinon je peux exécuter mon prog... Mon souci c'est qu'il est facile de créer le fichier au lancement de l'instance de mon programme mais que je dois m'assurer que dans tous les cas quand celui-ci se termine le fichier "flag" est bien supprimé... Dois-je utiliser pour cela un "Shutdown hook" ???
 
Est-ce-que vous voyez une meilleure solution ?
 
Merci

problème intéressant. Est ce que ton programme utilise une resource réseau quelconque (genre ouvre un serversocket sur un port bien donné?).
 
Pour le fichier ce n'est pas spécialement mauvais, même si c'est pas top (je connais des produits open source qui utilisent ce mécanisme).
 
Pour le shutdown hook tu pourrais eventuellement utiliser ce concept mais à mon avis theFile.deleteOnExit() devrait etre plus propre.

+1 pour le fichier, dans /var/lock en faisant gaffe, que ça peut quand même être un système de fichier réseau (bien que ce soit peu probable).
 
et +1 pour le deleteOnExit().

 
Oui mon programme utilise un port pour communiquer avec un serveur mais la collision entre les 2 instances n'intervient pas sur cet aspect. Mon programme utilise une API qui crée un fichier dont je ne peux pas modifier le nom car il est codé en dur... Quand mon 1er prog se lance, il sauve dans ce fichier un identifiant de session sur 4 positions alphanumériques. Quand le second se lance, il écrit son id de session dans le même fichier, faisant ainsi planter la 1ère instance...
 
Utiliser un fichier comme "flag externe" me paraît pas mal mais je suis pas sûr que ça soit sûr dans les cas tordus de  lancement simultané de 2 instances...
 
Pour le theFile.deleteOnExit(), je connaissais pas, merci    Avec ça, je suis sûr que la ressource est nettoyée proprement

 
Vos appréciations me rassurent. C'est parti pour le code  

bin pq tu ne regardes pas si le port en question est bindé au tout début. Si c'est le cas tu as une autre instance qui tourne et basta

ouais, moi j'aurais utilisé un port plutot qu'un fichier : c'est l'os qui ferme le port à la fermeture du programme ...

d'un autre coté le bind du port ne se fait pas immédiatement au lancement du prog aussi

Bon je suis pas trop calé côté bind de port Tout ce que je sais c'est que mon programme communique avec un serveur sur un port donné mais que je n'ouvre pas de port explicitement. L'API que j'utilise le fait probablement de manière transparente mais si c'est le cas je n'ai jamais observé de collision entre 2 instances de mon client...
 
Je vais m'en tenir à l'utilisation d'un fichier externe comme "lock"

nan mais il aurait fallu que ton client ouvre un port avec un server socket. comme ca au démarage, le client essaye d'ouvrir le port. Si ca marche pas c'est qu'il est déjà utilisé par un autre client ...
 
en faite, ca revient à ouvrir un port pour rien quoi ...

ok, j'avais pas compris. Mais vous me mettez le doute maintenant...    Est-ce-que le port sera libéré dans tous les cas de figure de terminaison du prog comme ça serait le cas en utilisant la méthode "theFile.deleteOnExit()" ???

Bon, je viens de trouver ceci dans la javadoc de la méthode createNewFile() de File:
 
Atomically creates a new, empty file named by this abstract pathname if and only if a file with this name does not yet exist. The check for the existence of the file and the creation of the file if it does not exist are a single operation that is atomic with respect to all other filesystem activities that might affect the file. This method, in combination with the deleteOnExit() method, can therefore serve as the basis for a simple but reliable cooperative file-locking protocol.
 
 

moralité : "lire la javadoc cai bieng "