JQuery AJAX appel à WebMethod multi-thread

Question

J'ai un appel JQuery AJAX pour ASP.NET WebMethod.

Je comprends le async: true qui permet à la page Web de ne pas être verrouillé jusqu'à ce que la fonction retourne et donc je l'ai mis à 'true'.

Le problème que je suis confronté est que la méthode interne GetVersionFromDataBase() à l'intérieur de la GetVersion() prend beaucoup de temps jusqu'à ce qu'il se termine, et pendant ce temps l'ensemble du backend est verrouillé (un seul thread).

L'expérience de l'utilisateur est que pour l'autre utilisateur qui navigue sur le site, même sur des pages différentes, leur écran est verrouillé jusqu'à ce que la méthode «lourde» retourne.

Comment puis-je rendre la fonction GetVersionFromDataBase() dans un thread/des tâches différents?

$.ajax({ 
    type: "POST", 
    url: "Default.aspx/GetVersion", 
    contentType: "application/json; charset=utf-8", 
    dataType: "json", 
    async: true, 
    success: function (result) { 
     alert('the version is:' + result.d); 
    } 
}); 



public partial class Default : System.Web.UI.Page 
{ 
    [WebMethod] 
    public string GetVersion() 
    { 
     string version = GetVersionFromDatabase(); // this is a heavy method freezes the program till it finishes 
     return version; 
    } 
} 

Answer 1

EDIT: @Rob est droite, un long processus en cours d'exécution a démarré par un utilisateur (même la façon dont vous le faire) ne devrait pas affecter vraiment d'autres utilisateurs, à moins qu'il est vraiment en train de manger tous vos cycles CPU et la mémoire .. Dans ce cas, mon approche ci-dessous n'aiderait pas avec ce problème.

Il existe plusieurs manières d'aborder ce problème (un processus ASP.NET à exécution longue). J'ai toujours utilisé un thread d'arrière-plan côté serveur avec une approche d'interrogation côté client. Cela signifie que votre application fonctionnera comme ceci:

1) Le client indique qu'il souhaite démarrer le processus de longue durée.

2) Le serveur démarre le processus dans un thread d'arrière-plan et renvoie un identifiant unique au client.

3) Le client attend un certain temps et demande au serveur "Sommes-nous encore là?" (Pensez aux enfants sur le siège arrière d'un long trajet en voiture) En passant à cette question l'identifiant de l'étape 2, de sorte que le serveur sait quel travail vérifier pour l'achèvement.

4) Le serveur répond «Pas encore ...» (retour à l'étape 3) OU «Oui, nous sommes là ...» (passez à l'étape 5).

5) Le processus en cours d'exécution est terminé. Il est probable que le client demande ensuite des résultats au serveur et les affiche, ou indique simplement à l'utilisateur que le travail est terminé.

Maintenant - comment coder ceci? C'est une ressource que je l'ai utilisé pendant quelques années et il m'a bien servi, je l'ai fait quelques modifications mineures aux classes mais dans l'ensemble l'approche est solide:

http://www.devx.com/asp/Article/29617

Voici une autre :

http://www.allannienhuis.com/archives/2010/11/27/long-running-asp-net-processes-a-simple-example/

une chose à considérer lorsque vous codez c'est si votre application ne sera jamais servi dans un environnement EQUILIBRE dE CHARGE. Si tel est le cas, vous devrez peut-être configurer des «sessions persistantes» ou vous assurer que la clé unique de l'identificateur de travail et son travail associé sont accessibles depuis chaque serveur Web. Prendre plaisir!

Answer 2

Cela ne se produira que sur le serveur Web de développement et non dans IIS dans un environnement de production.

ASP.NET Development Server concurrent processing doesn't work