BackgroundWorker à partir d'une application ASP.Net

Question

Nous disposons d'une application ASP.Net qui permet aux administrateurs de travailler avec et d'effectuer des opérations sur de grands ensembles d'enregistrements. Par exemple, nous avons un " Polish Data " tâche qu'un administrateur peut effectuer pour nettoyer les données d'un enregistrement (par exemple, reformater des numéros de téléphone, des numéros de sécurité sociale, etc.) Lorsqu'elle est exécutée sur un petit nombre d'enregistrements, la tâche se termine assez rapidement. Toutefois, lorsqu'un utilisateur exécute la tâche sur un ensemble d'enregistrements plus volumineux, la tâche peut durer plusieurs minutes ou plus. Donc, nous voulons implémenter ce type de tâches en utilisant une sorte de modèle asynchrone. Par exemple, nous souhaitons pouvoir lancer la tâche, puis utiliser l'interrogation AJAX pour fournir une barre de progression et des informations sur l'état.

J'ai étudié la possibilité d'utiliser la classe BackgroundWorker, mais j'ai lu certaines choses en ligne qui me font réfléchir. J'aimerais avoir des conseils supplémentaires à ce sujet.

Par exemple, je comprends que BackgroundWorker utilisera réellement le pool de threads de l'application actuelle. Dans mon cas, l'application est un site Web ASP.Net. J'ai lu que cela peut poser un problème car, lorsque l'application est recyclée, les travailleurs d'arrière-plan sont supprimés. Certains des travaux que j'ai mentionnés ci-dessus peuvent prendre 3 minutes, mais d'autres peuvent durer quelques heures.

De plus, plusieurs centaines d’administrateurs peuvent effectuer des opérations similaires au cours de la journée. Le pool de threads d'application ASP.Net sera-t-il capable de gérer efficacement tous ces travaux en arrière-plan tout en effectuant son traitement de requête normal?

J'essaie donc de déterminer si l'utilisation de la classe et de l'approche BackgroundWorker convient à nos besoins. Devrais-je envisager une approche alternative?

Merci et désolé pour un si long post!

Kevin

Answer 1

Dans votre cas, il semble que la solution à rechercher soit multiple (et non un projet simple et abouti).

Comme vous avez dit que certains processus peuvent durer des heures, ce n’est absolument pas quelque chose que ASP.NET possède. Cela doit être exécuté dans un service Windows et géré avec un thread Windows natif.

Vous devrez implémenter un type de file d'attente de travail dans votre service et un moyen de communiquer avec la file d'attente. Une solution consiste à exposer un service WCF pour toutes les actions que votre service gouverne. Une autre solution consisterait à ce que service interroge une table de base de données et récupère le travail de la table.

Pour pouvoir exprimer le statut du processus, vous souhaiterez que l'application ASP.NET puisse avoir une référence à l'ID de processus. Par exemple, le service WCF renvoie un identificateur GUID. Ensuite, vous avez une méthode qui, lorsque vous lui donnez l'ID de processus, retournera le statut du processus. Vous pouvez ensuite mettre en œuvre l'interrogation de cet appel de service à l'aide d'AJAX et afficher le type de modal de votre choix.

Une autre chose à retenir est que vous devez concevoir vos processus de manière à savoir où ils se trouvent et où ils se trouveront quand ils seront terminés afin de pouvoir suivre l'état dans lequel ils se trouvent. Par exemple, BatchJobA est exécuté et aura 1000 enregistrements à traiter. Le service doit savoir sur quel enregistrement il se trouve ou quel est le% de concurrence actuel pour pouvoir renvoyer des informations à l'interface utilisateur. Pour les requêtes SQL qui prennent beaucoup de temps à exécuter, il peut être très difficile de jauger avec précision son emplacement, à moins que vous ne fassiez beaucoup de pré-traitement et de post-traitement des tables temporaires pour pouvoir lire au centre le statut des tables temporaires. comprendre où il se trouve.

Answer 2

Sur la base de ce que vous dites, je pense que BackgroundWorker n’est pas un bon choix.

En outre, le fait de conserver cette fonctionnalité dans votre application principale peut être problématique, notamment parce que vous ne souhaitez pas que le traitement soumis soit interrompu si l’application principale est recyclée. Vous pouvez jouer avec le traitement asynchrone, mais cela fera toujours partie de l'application principale AppDomain - tout cela mourra si l'application se recycle.

Je suggérerais de créer une application distincte implémentant cette fonctionnalité. Dans une situation similaire, j’ai séparé le traitement en arrière-plan d’un service Windows et y ai hébergé un service Web comme moyen de communication

Answer 3

Vous pourriez envisager une approche légèrement différente.

Par exemple, disposez d'une table de commandes et de contrôles dans laquelle vous envoyez des commandes du type "NUMÉROS DE TÉLÉPHONE REFORMAT". ou peu importe.

Ensuite, demandez à un service Windows de surveiller cette table. Chaque fois qu'un enregistrement apparaît, exécutez la commande.

Ceci élimine toute inquiétude concernant un fil d’arrière-plan. De plus, vous disposez d'un peu plus de flexibilité en ce qui concerne le contenu de la file d'attente, l'ordre des opérations, y compris la priorité, etc. Enfin, vous obtiendrez une liste définitive de ce qui est en cours d'exécution ou à exécuter.

En option, au lieu d'un service Windows, vous pouvez simplement utiliser un travail SQL pour s'exécuter de temps en temps afin de surveiller votre table de contrôle et d'effectuer l'action demandée.