Solution au problème de requête de course longue dans une application Web (demande asynchrone)

La solution que j'ai utilisée avant implique Jetty Cometd au lieu d'Ajax. La principale différence entre Ajax et Cometd est que Cometd peut utiliser davantage d'un pub / sous-modèle - le client (navigateur Web dans ce cas) Subsribe à l'éditeur (votre application) et de l'application pousse les mises à jour et les notifications au navigateur Web comme Apposé à un modèle Ajax d'interrogation constante du serveur par le navigateur Web. Vous pouvez utiliser la solution Cometd même si vous n'utilisez pas de jetée - vous pouvez déposer les pots de jetty dans le dossier LIB de votre serveur Web respectif et que vous devriez être prêt à partir.

Combien de temps fonctionne ces requêtes?

Si vous parlez de sessions expirant, il est peut-être préférable que l'utilisateur ne soit pas attendu pour cela. Il sera toujours gênant que l'utilisateur attendra 20 minutes de pointe de temps en temps dans cette onglet de la requête.

Donc, si des requêtes vraiment longues sont le cas, il est peut-être préférable de changer l'approche d'interface utilisateur et d'avoir l'utilisateur "commander" une requête qu'il revient plus tard à la vue ou est même notifiée par courrier .

Dans un tel cas, je disposerais de la requête préparée dans la DB et la mise en cache, dans une table séparée, là-bas. Signification, je aurai que le serveur Web fonctionne une fois pour enregistrer la demande, disposer d'une tâche DB ou d'un processus / serveur distinct préparez des requêtes sur les demandes et informez-en l'utilisateur, puis auquel le serveur Web l'affiche lorsque l'utilisateur revient pour le Résultats.

Je ferais une combinaison de votre "mauvaise solution" et de la "solution J2EE":

1. Le fil d'interface utilisateur d'origine envoie un message JMS asynchrone au "Backend" et retourne.
2. Le backend reçoit la requête asynchrone et le traite.
3. Lorsqu'un résultat (ou une erreur) est atteint dans le backend, il est renvoyé à la couche de contrôleur.
4. l'interface utilisateur, qui fait toujours l'interrogation Ajax ou en utilisant Bayeux / Comété, reçoit et affiche le résultat.

   L'astuce consiste à faire correspondre la paire de demandes / de réponse. Je le ferais comme ceci:

   1. créer un "asyncmanagerservice" (AMS) qui a une session, peut-être même une large portée de l'application afin que tous les threads parlent à la même instance.
   2. L'AMS contient une carte avec une identification comme clé et n'importe quel objet comme valeur.
   3. Lors de la création du message JMS de la demande, génère une clé aléatoire unique et placez-la dans le jmscorrélationid du message ainsi que dans la carte, avec null comme valeur. Également passer cet identifiant à l'interface utilisateur.
   4. Laissez le thread de l'UI sondre l'AMS avec l'identifiant précédemment généré aussi longtemps que la valeur de la carte est null . .
   5. Lorsque le résultat est prêt, laissez votre récepteur JMS dans la carte AMS à l'ID donné.
   6. La prochaine fois que le fil de l'interface utilisateur interroge la carte, il recevra la réponse et arrêtera le sondage.

      Ceci est propre et bien résumé de tout domaine concret . Une solution purement technique.

      Même si vous n'aimez pas le sondage, HTTP est apatride à la conception et je pense que ce sondage ne se produit que sur des intervalles bien définis.

      Quoi qu'il en soit, j'ai mis en place un système avec exactement ce modèle et il fonctionne simplement bien ...