Hier liegt das Problem

Ein Benutzer einer Unternehmens-Webanwendung führt eine Aufgabe aus, die zu einer langen (sehr langen) Datenbankabfrage (oder einer anderen langen verarbeitungsintensiven Aufgabe) führt.

Probleme:

Anforderungs-Timeout - Nach einiger Zeit kann es vorkommen, dass der Benutzer ein Anforderungs-Timeout erhältSitzungs-Timeout - Wenn keine Sitzungsmethoden verwendet werden, kann ein Sitzungs-Timeout auftretenThread-Sperre anfordernDa der Anforderungsthread nicht zurückgibt, werden möglicherweise neue Anforderungen blockiert (wenn das Poollimit erreicht ist).In einigen Anwendungsservern kann der Integritätsstatus des Servers einen erzwungenen Neustart des Knotens oder der Anwendung auslösen (aufgrund eines lange laufenden Anforderungsthreads).Wenn der Benutzer die Seite verlässt:Die Transaktion wird nicht abgebrochen, was zu einer nutzlosen Verarbeitung führt, von der niemand profitiertDer Benutzer kann nicht zurückkehren, um die Ergebnisse anzuzeigen, nachdem sie abgeschlossen wurdenKeine Fortschrittsanzeige - Der Benutzer wartet nur auf die Aktualisierung der Seite

Ich habe mehrere Lösungen gefunden, bin mir aber nicht sicher, welche besser sind (in allen Aspekten, Leistung, Best Practice, Eleganz und Wartbarkeit), und ich würde gerne wissen, welche Lösung Sie empfehlen und ob es welche gibt eine Lösung, die ich verpasst habe? (wahrscheinlich ja und viele)

Die schlechte Lösung: Verwenden Sie den Anforderungsthread als Arbeitsthread, speichern Sie den Fortschrittsstatus in der Sitzung, lassen Sie einen AJAX-Aufruf den Status (in der Sitzung) in einer anderen parallelen Anforderung überprüfen

Die Kompromisslösung: Erstellen Sie Ihren eigenen Thread-Pool, behandeln Sie einen Überwachungsthread, einen Arbeitsthread und kümmern Sie sich um das Clustering, indem Sie die Status entweder in einem verteilten Transaktionscache oder in einem dauerhaften Speicher synchronisieren. Dadurch wird die Anforderung freigegeben, es werden jedoch Threads erstellt, die dem Anwendungsserver nicht bekannt sind, und die bei einer Aufhebung der Bereitstellung nicht geschlossen werden. Es liegt an Ihnen, Threads auf saubere Weise herunterzufahren, und es besteht immer die Möglichkeit, dass am Ende etwas ausläuft. Dies ist auch nicht die J2EE-Methode.

Die J2EE-Lösung: Verwenden Sie JMS für die asynchrone Aufgabe

die Frühlingslösung: Spring Batch verwenden

Was würden Sie in Ihren Projekten tun / tun? Welche anderen Lösungen kennen Sie? Welcher der oben genannten Gewinner ist Ihrer Meinung nach der Gewinner?