Discussion :

[Bash01]

Bonjour,

Je travaille actuellement sur un outil permettant de convertir un ensemble de fichiers images, contenu dans un même dossier, vers un autre format d'image dans un autre dossier (ou le même...). Le programme serait lancé en tâche de fond et exécute de manière périodique son code, qui traiterait ainsi les nouveaux fichiers ajoutés entre n et n+1

Le métier du programme est codé et fonctionne à merveille, pour une instance. Néanmoins, j'aimerais pouvoir lancer plusieurs instances de ce programme sur la même machine (voire plusieurs machines, plus tard) afin que le traitement de fasse de manière parallèle et la problématique étant bien sûr que les différentes instances ne doivent pas traiter le même fichier, ni les fichiers déjà traités.

J'utilise pour l'instant un Timer et une classe dérivant de TimerTask.

Quelqu'un aurait-il une solution à me proposer ?

Merci?

[SamSer]

Je pense qu'il est facilement possible de gèrer le problème avec une db.

Plus explicitement: tu nourris ta bd en spécifiant quel fichier a été traité, est traité ou est en attente de traitement. De cette manière, tu peux avoir autant d'instance que tu le désires, il n'y aura pas de conflits.

[Bash01]

Oui, j'y ai aussi pensé. Malheureusment, je n'ai pas le droit d'en utiliser une. Du coup, la seule solution que j'ai trouvé pour le moment est un fichier texte dans lequel j'ajoute le nom des fichiers traités à chaque fois, mais cette solution n'est pas forcément fiable et est surtout très couteuse en temps car le programme doit reconsulter l'intégralité du fichier à chaque itération de la boucle...

Du coup, je cherche toujours une solution optimale.

[Rei Ichido]

Tu ne peux pas faire bouger tes fichiers ? Ou bien créer des fichiers .lock vides ?

Cela dit, fais attention car avec ce genre de méthode, on prend toujours le risque de conflits !

[SamSer]

Oui, j'y ai aussi pensé. Malheureusment, je n'ai pas le droit d'en utiliser une. Du coup, la seule solution que j'ai trouvé pour le moment est un fichier texte dans lequel j'ajoute le nom des fichiers traités à chaque fois, mais cette solution n'est pas forcément fiable et est surtout très couteuse en temps car le programme doit reconsulter l'intégralité du fichier à chaque itération de la boucle...

Du coup, je cherche toujours une solution optimale.

Pour quelle raison tu n'as pas le droit d'utiliser une db? Je suis vraiment curieux de savoir...

Sinon pour le fichier, tu n'es pas obligé de tout stocker dans un seul fichier mais dans plusieurs en utilisant la logique que tu désires pour optimiser les accès.

Si tu es obligé d'utiliser un seul fichier, alors il vaut mieux selon moi écrire un programme indépendant qui se charge sur demande des instances que tu lances, de lire et de nourrir le fichier.

[Bash01]

Pour quelle raison tu n'as pas le droit d'utiliser une db? Je suis vraiment curieux de savoir...

Juste parce que c'est une application d'entreprise et que je n'ai pas le droit de toucher à leur BD existante ou en créer une autre pour l'utiliser. Quand il s'agit de grosse boîte, généralement on n'a pas trop le droit de toucher au SI existant...

Sinon merci pour les solutions, je sais qu'aucune d'entre elles ne garantit un résultat 100% fiable, mais c'est déjà mieux que ma solution...

[tchize_]

on a pas dit que tu devais "installer" une base de donnée, il existe suffsament de bases de données pur java (HSQLDB, Derby, H2, SQLIte) ne necessitant pas de maintenance pour que ca n'affecte pas leur SI et que ça soit considéré comme faisant partie de ton application

[Heimdal]

Pourquoi ne pas simplement faire du multi-threading?

[tchize_]

La base de donnée partagée est la seule solution pratique si tu veux faire du multi-machines. Les .lock c'est bien joli mais souvent ça se casse les dents sur des dossiers réseau (seul des dossiers locaux peuvent donner des garanties sur la création de fichiers lock). Un alternative, ce serait d'avoir toutes tes application qui discuttent, par exemple, en multicast sur le réseau pour savoir qui fait quoi, mais c'est se tapper le travail d'implémentation d'un sémaphore distribué, bonne chances.

Maintenant, si tu travaille dans une seule machine, je vois pas l'intéret de lancer plusieurs JVMs plutot que de faire du multi-thread dans une seule

Après il reste les solutions approximative: si pas de .lock ou si .lock "vieux", on le crée et on fait le traitement, en acceptant que occasionellement 2 process traitent le même fichier.

[sinok]

Maintenant, si tu travaille dans une seule machine, je vois pas l'intéret de lancer plusieurs JVMs plutot que de faire du multi-thread dans une seule

Pour des histoire d'optimisation de l'utilisation des ressources système (sur des systèmes multi-coeur, multi proc assez bourrins, pas sur que ce soit le cas ici) il est de temps en temps préférable d'avoir N JVM de taille moyenne tournant qu'une méga JVM over threadée. En effet l'ordonnanceur de l'OS gère de façon différente les process et le threads (Sinon quel intérêt aux clusters verticaux?)