Lösung für das lange laufende Abfrageproblem in einer Webanwendung (asynchrone Anfrage)

Ich würde eine Kombination aus Ihrer sogenannten "schlechten Lösung" und der "j2ee-Lösung" machen:

1. Der ursprüngliche UI-Thread sendet eine asynchrone JMS-Nachricht an das "Backend" und gibt
zurück
2. Das Backend empfängt die asynchrone Anfrage und verarbeitet sie.
3. Wenn ein Ergebnis (oder Fehler) im Backend erreicht wird, wird es an die Controller-Schicht zurückgegeben.
4. Die Benutzeroberfläche, die gerade AJAX-Abfragen durchführt oder Bayeux / Cometed verwendet, empfängt und zeigt das Ergebnis an.

Der Trick besteht darin, das Anfrage / Antwort-Paar zu vergleichen. Ich würde es so machen:

1. Erstellen Sie einen "AsyncManagerService" (AMS) mit SESSION, vielleicht sogar APPLICATION, so dass alle Threads mit derselben Instanz kommunizieren.
2. Das AMS enthält eine Karte mit einer ID als Schlüssel und einem beliebigen Objekt als Wert.
3. Erstellen Sie beim Erstellen der JMS-Nachrichtenanforderung einen eindeutigen Zufallsschlüssel und fügen Sie ihn in die jmsCorrelationId der Nachricht sowie in die Karte ein, wobei NULL als Wert verwendet wird. Übergeben Sie diese ID auch an die Benutzeroberfläche.
4. Lassen Sie den UI-Thread das AMS mit der zuvor generierten ID abfragen, solange der Wert in der Karte NULL ist.
5. Wenn das Ergebnis fertig ist, lassen Sie es von Ihrem JMS-Empfänger unter der angegebenen ID in die AMS-Karte einfügen.
6. Wenn der UI-Thread das nächste Mal die Karte abfragt, erhält er die Antwort und stoppt die Abfrage.

Dies ist sauber und gut abstrahiert von jeder konkreten Domäne . Eine rein technische Lösung.

Auch wenn Sie das Polling nicht mögen, ist HTTP statuslos und ich denke, dass die Abfrage nur in genau definierten Intervallen erfolgt.

Wie auch immer, ich habe ein System mit genau diesem Muster implementiert und es läuft gut ...

Die Lösung, die ich vorher benutzt habe, beinhaltet Jetty Cometd anstelle von AJAX. Der Hauptunterschied zwischen Ajax und Cometd ist, dass Cometd mehr von einem Pub / Sub-Modell verwenden kann - der Client (Webbrowser in diesem Fall) abonniert den Publisher (Ihre App) und die App schiebt Updates und Benachrichtigungen an den Webbrowser als an ein Ajax-Modell der konstanten Abfrage des Servers durch den Web-Browser. Sie können die Cometd-Lösung auch dann nutzen, wenn Sie keinen Jetty verwenden - Sie können die Jetty-Jars in den lib-Ordner Ihres jeweiligen Web-Servers legen und es sollte Ihnen gut gehen.

Zeigen Sie dem Benutzer eine Nachricht, dass "Ihre Anfrage akzeptiert wird und es eine Stunde dauern wird, bis sie aktualisiert wird"

Sie erstellen eine Tabelle, die alle diese Transaktionen speichert und diese in einem Stapel auf dem Server verarbeitet.

Der Benutzer muss nicht lange warten und er wird sich freuen, die Nachricht zu sehen. Sie können eine Bestätigungs-E-Mail senden, sobald Ihre Transaktion verarbeitet wurde.

Dies ist die beste Lösung, denke ich.

Wie lange laufen diese Abfragen?

Wenn Sie davon sprechen, dass Sitzungen auslaufen, ist es vielleicht am besten, wenn der Benutzer nicht darauf wartet. Es wird immer lästig sein, wenn der Benutzer 20 Minuten lang auf dem Tab der Abfrage warten muss.

Also, wenn wirklich lange Abfragen der Fall sind, ist es vielleicht am besten, den UI-Ansatz zu ändern und den Benutzer dazu zu bringen, eine Abfrage zu "bestellen", die er später wieder ansieht oder die sogar per Mail benachrichtigt wird .

In einem solchen Fall würde ich die Abfrage in der Datenbank vorbereiten und in einer separaten Tabelle zwischenspeichern. Das heißt, ich würde den Webserver einmal arbeiten lassen, um die Anfrage zu registrieren, eine DB-Aufgabe oder einen separaten Prozess / Server auf Anfragen vorbereiten und den Benutzer benachrichtigen, und dann den Webserver anzeigen lassen, wenn der Benutzer für die zurückkommt Ergebnisse.