2010-02-19 2 views
0

Dans un gestionnaire HTTP asynchrone, nous ajoutons des éléments au cache ASP.NET, avec des dépendances sur certains fichiers. Si la méthode async exécute sur un fil de la ThreadPool, tout va bien:ASP.NET CacheDependency hors ThreadPool

AsyncResult result = new AsyncResult(context, cb, extraData); 
ThreadPool.QueueUserWorkItem(new WaitCallBack(DoProcessRequest), result); 

Mais dès que nous essayons d'exécuter sur un fil de la ThreadPool:

AsyncResult result = new AsyncResult(context, cb, extraData); 
Runner runner = new Runner(result); 
Thread thread = new Thread(new ThreadStart(runner.Run()); 

... où Runner.Run n'appelle que DoProcessRequest,

Les dépendances se déclenchent juste après la fermeture du thread. C'est à dire. les éléments sont immédiatement supprimés du cache, la raison étant les dépendances.

Nous souhaitons utiliser un thread hors pool car le traitement peut prendre beaucoup de temps.

Donc, de toute évidence, quelque chose manque quand nous créons le fil. Nous pourrions avoir besoin de propager le contexte d'appel, le contexte http ...

Est-ce que quelqu'un a déjà rencontré ce problème?

Remarque: les pools d'unités d'alimentation personnalisés disponibles sur le marché résoudront probablement ce problème. L'écriture de notre propre pool de threads est probablement une mauvaise idée de (think NIH syndrom). Pourtant, je voudrais comprendre cela dans les détails, cependant.

Répondre

0

Impossible de comprendre les détails ... Nous avons trouvé une solution de contournement, cependant: dans la plupart des implémentations IAsyncResult, une fois l'opération terminée, un appel direct est lancé vers le rappel. Nous avons remplacé cela, et maintenant mettre en file d'attente le rappel dans le ThreadPool. Par conséquent, le rappel s'exécute dans le ThreadPool et peut enregistrer les dépendances qui durent.

Questions connexes