Discussion :

[maitrebn]

Bonjour,

Je suis à la recherche d'une piste ou d'une idée pour gérer des processus concurrents effectuant le même travail.

Donc mon application, j'ai une partie qui synchronise des données avec un serveur Distant (SQL Server 2000 ou 20005). Cette fonctionnalité est directement appelable dans l'applicatif.

Pour des raisons de flexibilités, il est prévu de pouvoir délocaliser ce traitement de synchronisation sur une autre machine. Le but étant de synchroniser de façon silencieuse à des moments de moins forte occupation du réseau.

Le HIC c'est que j'aimerais éviter que des traitements ne fassent la même chose en même temps (probabilité réduite mais je suis un fan de la loi de murphy) en m'assurant que deux processus ne vont pas lancer la même synchro ...

J'ai pas mal d'idée : flags dans une table en bas, flag dans un fichier mais je suis confronté au même problème : que se passe-t-il si un process ne va pas au bout et ne gère pas la suppression de son flag ???

Bref, je cherche des suggestions ou des pistes ...

[LefortLudovic]

Là tu rentres dans le multi threading sur plusieurs machines .... Aille

Il y a des objets .net que te permettes de faire cela comme le MUTEX et le SEMAPHORE mais je n'ai jamais vrament creusé.

Bonne chance

[Sphax]

Salut,

Pour un problème similaire j'avais opté pour:
- une espece de flag en base de donnée (la base elle même gérant l'accés concurrent à ce flag) , le flag consistant en l'adresse du processus (nom de machine, port d'écoute, ce genre de choses)
- un autre processus voulant faire la même tâche récupère le flag, si un autre processus est passé avant lui il l'interroge pour lui demander si tout va bien et agit en conséquence : soit il prend lui même le flag car l'autre processus semble avoir un problème, soit il passe à autre chose car tout va bien.

A l'époque mes processus communiquaient en remoting, je suppose que maintenant je regarderais du côté de communication foundation.

[SaumonAgile]

Dans ce cas, pour simplifier tu peux utiliser un processus maitre qui va gérer ce flag. De cette manière, tu sais que le flag ne sera modifié que part une seule "personne". Les autres processus vont interroger le maitre pour obtenir le travail à effectuer. Il te sera plus facile de rajouter des travailleurs par la suite.

La deuxième chose qui te simplifiera la vie est que tu ne devrais avoir qu'une seule méthode pour demander si le travail est dispo et pour le réserver. Cela d'évitera de gérer les problèmes de réservation de la ressource par un autre processus entre le moment où je demande si la ressource est dispo et le moment où je demande à réserver la ressource.

[maitrebn]

Merci à tous !

Le truc que je vois pas bien dans vos propositions, c'est la gestion du plantage d'une des applications. Les machines étant des portables, je ne suis pas à l'abri d'un utilisateur qui débranche le cable et s'en va ...

Je vais regarder tout cela en détail ...

[cinemania]

ajoute un champ de type datetime dans ton flag base de données.

Ce champ datetime contient le moment où cette opération a été prise par un process. Si le process au bout d'une heure par exemple n'a pas supprimé son flag, on est en droit de ce dire que celui-ci a probablement planté.

Il est d'ailleurs possible de demander au process maitre s'il a des nouvelles du thread qui a demander à faire cette tache. S'il n'a aucune nouvelles... tu peux le faire à ton tour, car si l'utilisateur a débranché le cable, les opérations sont stoppées (et sur un systeme transactionnel, par défaut elle seront annulées si incomplètes, ou tu peux gérer ca toi meme avec des triggers sql.)

Dans le meme aspect, tu peux partir du principe que tous tes process ouvre un port tcp de communication. Quand un effectue une tache il envoie un flag sur la base, en précisant la nature de la tache, son ip, le service en cause ...
Si un autr eprocess voit que cette tache est en cours... il peut chercher à contacter le process qui effectue cette tache, sur le port TCP. Si celui ci répond qu'il est encore dessus, ou qu'il a pas encore eu le temps de libérer le flag... tant mieux, si en revanche ya pas de réponse... (timeout) tu peux supposer à juste titre que le process est soit "dead" soit déconnecté du réseau... (dans ce cas, les opérations déja faites ont été annulées normallement si ta bien programmé) et c'est à ce process qui constate le probleme d'y remedier en annulant le flag et en en mettant un autre à disposition.

Rien de vraiment transcendant