Discussion :

[Invité]

Bonjour,

J'essaye de concevoir un système qui limiterai le nombre d'instance de mon programme qu'il est possible de lancer en même temps (1 seule).

Pour cela, j'utilise le verrouillage de fichier RandomAccessFile.getChannel().tryLock().
Si le programme arrive à verrouiller le fichier (1ere instance), il écrit dedans des informations.
Si il n'arrive pas à verrouiller le fichier (instance secondaire), il lit les informations déjà écrite.

Le problème, c'est que dans le cas d'une instance secondaire, le programme n'arrive pas à lire le contenu du fichier, car celui ci est verrouillé.
Et je ne peux pas déverrouiller le fichier depuis la 1ere instance, car sinon l'instance secondaire arriverait à le verrouiller (et ça perd tout l'intérêt).

Je voudrais donc pouvoir verrouiller le fichier (en écriture), mais qu'il reste accessible en lecture.

Des idées ?

Merci

[dingoth]

Plus efficace : ouvre un socket client vers un port X. Si tu ne parviens pas à l'ouvrir, ouvre ce port en serveur (pour que les instances futures puissent l'écouter). Si tu parviens à l'ouvrir, c'est que tu as affaire à une instance de ton programme qui existe déjà.

[laclac]

http://java.developpez.com/faq/java/...ngage_fichiers

[Invité]

Plus efficace : ouvre un socket client vers un port X. Si tu ne parviens pas à l'ouvrir, ouvre ce port en serveur (pour que les instances futures puissent l'écouter). Si tu parviens à l'ouvrir, c'est que tu as affaire à une instance de ton programme qui existe déjà.

la logique voudrait qu'on ouvre d'abord un port XXX en serveur, et si on y arrive pas, on se connecte dessus en client.

Le problème, c'est que le port XXXX est défini de manière fixe. Et il y a une possibilité (minime) que ce port soit dejà occupé par un autre programme. Donc ça casse tout.

@laclac : rien trouvé à cet endroit là

[Invité]

l'algo de mon programme

- ouverture et création d'un fichier (avec RandomAccessFile)
- tentative de verrouillage du fichier, avec le FileChannel et tryLock()
- Si le verrouillage réussi :
------ Ouverture d'un port TCP serveur libre (n'importe lequel)
------ Ecriture du numéro de port dans le fichier
------ Lancement d'un Thread qui va ecouter sur le port TCP
- Si le verrouillage ne réussi pas (si il y a déjà un instance de lancée)
------ Lecture du fichier verrouillé et récupération du port précédemment écrit
------ Connexion TCP au port indiqué
------ Envoie d'information à la première instance via TCP

Cette méthode est parfaite (je ne pense pas me vanter), mais elle bug au niveau : "Lecture du fichier verrouillé et récupération du port précédemment écrit"

[Grimly_old]

Créez un fichier temporaire sans oublier d'appeler "File#deleteOnExit()"
Les chances de collision sont très minimes je pense.

N'oubliez (si vous utilisez SWING) de ne pas utiliser JFrame#EXIT_ON_CLOSE comme action de fermeture mais vérifiez avant la fermeture des sockets. Ce serait bête de perdre la connexion entre vos instances.

[Invité]

Et j'en fais quoi de ce fichier ?
Je vois pas très bien :/

[Grimly_old]

C'est simple :

Au lancement...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Si "./temp.tmp" existe alors
   Lire le fichier
   Récupérer le port de l'instance principale
   Fermer le fichier (Stream)
Sinon
   Créer le fichier, ne pas oublier de demander à la JVM de le supprimer une fois fini.
   Créer un ServerSocket
   Ecrire le numero de port du ServerSocket dans le fichier
   Fermer le fichier (Stream)
Fin

Il ne faut pas oublier de fermer vos flux (Input/OutputStream) pour éviter certains problèmes ennuyeux d'accès concurrents.
Il faut aussi veiller à ce que la première instance survive jusqu'à la fermeture des autres instances, sinon les liens entre instances se perdent.

[Invité]

ok je vois,
tu me proposes de tester l'existence du fichier,
alors que moi j'ai choisi le verrouillage de fichier.

le problème du test de l'existence de fichier, c'est qu'il est possible qu'un programme le supprime, ou le modifie
et donc il y a potentiellement une faille.

[Grimly_old]

ok je vois,
tu me proposes de tester l'existence du fichier,
alors que moi j'ai choisi le verrouillage de fichier.

le problème du test de l'existence de fichier, c'est qu'il est possible qu'un programme le supprime, ou le modifie
et donc il y a potentiellement une faille.

C'est un problème comme un autre. Entre le port fixe et le fichier à surveiller il faut au final faire un choix.
Je ne vois aucune autre alternative portable.

[Invité]

ce qu'il me faut, en fait, c'est un moyen de verrouiller un fichier en écriture/suppression, mais qu'il soit toujours accessible en lecture.

pour le moment, j'utilise le FileChannel.tryLock(), mais il y a surement une autre option

[dinobogan]

L'utilisation de la socket est lourd et compliqué.

Tu dois découper le problèmes en plusieurs sous-problèmes.
Donc tu vas utiliser deux fichiers :
1. Le premier est celui qui est verrouillé, toujours vide. Il permet de contrôler les instances multiples.
2. Le second contient les informations à dispositions des autres instances. Il est toujours lisible par tous le monde.

[Invité]

ok, je vois

Le fichier de verrouillage sert juste à indiquer qu'il y a une instance en cours.
Le deuxième fichier pourrait permettre de transmettre les informations de la seconde instance à la première instance. (il n'est pas verrouillé).

Dans ce cas, existe t-il un mécanisme pour dire à la première instance de surveiller les modifications sur le deuxième fichier ? (mis à part la surveillance répétée)

Merci

[dinobogan]

Dans ce cas, existe t-il un mécanisme pour dire à la première instance de surveiller les modifications sur le deuxième fichier ? (mis à part la surveillance répétée)

Tu changes complètement la problématique de départ.
Tu voulais empêcher une autre instance de se lancer, en lui transmettant une info.
Maintenant tu acceptes plusieurs instances de ton programme.
Explique clairement ce que tu souhaites obtenir car la solution technique sera différente selon les cas.

[Invité]

Je veux que si on tente de lancer une deuxième fois mon programme :
- Il y ai un mécanisme pour détecter qu'il y a déjà une instance de lancée
- Que les paramètres du deuxième lancement soient transmit à la première instance de mon programme
- Que la deuxième tentative de lancement avorte, d'une manière ou d'une autre

Imaginons le cas d'un visualisateur de document avec onglet.
Il est possible d'ouvrir plusieurs documents au sein du même programme.
La ligne de lancement ressemble à : "monProgramme monFichier"
Si il y a déjà une instance de mon programme en cours, je voudrais que le nom de monFichier soit transmit à la premiere instance (puis que la deuxieme se ferme)

Quand je dis que la deuxième instance doit se fermer, ça signifie que sont lancement est interrompu. Un peu comme une exception qui arrete la création d'un objet.