Question

Voici mes hypothèses de base:

  1. Wcf exécute mes méthodes d'opération de service sur les threads IOCP (UnsafeQueueNativeOverlapped) au lieu des threads ThreadPool (QueueUserWorkItem) normaux.

  2. Le blocage des E / S ne doit pas ne pas être effectué à l'intérieur de méthodes d'opération de service unidirectionnel.

  3. Le blocage des E / S ne doit pas être effectué à l'intérieur d'un thread ThreadPool normal.

Je pense que la meilleure stratégie consiste à enchaîner les appels asynchrones . Donc, si je reçois un message dans mon service unidirectionnel, je passe ensuite un appel asynchrone à ma base de données et, une fois cette opération terminée, lance mon prochain appel de base de données asynchrone, etc. et répond enfin via mon rappel wcf ...

Cependant, il est difficile de faire chaque appel de base de données asynchrone. J'ai eu recours à la violation des règles 2 et 3 ci-dessus, mais je n'aime pas cela parce que je crois que cela va affamer le ThreadPool. Existe-t-il de meilleures stratégies?

J'ai envisagé d'utiliser le CustomThreadPool de Jon Skeet, mais je ne suis pas sûr que ce soit la solution non plus.

Était-ce utile?

La solution

Je suggérerais de rompre la règle 3 en mettant en file d'attente les appels d'E / S synchrones que le ThreadPool doit exécuter. Les méthodes de service sont toujours renvoyées immédiatement, mais le travail est finalement effectué en arrière-plan, éventuellement en lançant une notification de retour.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top