Решение проблемы длительных запросов в веб-приложении (асинхронный запрос)

Вот проблема

Пользователь корпоративного веб-приложения выполняет задачу, которая приводит к длинному (очень длинному) запросу к базе данных (или другой длительной обработке, требующей больших затрат)

Проблемы:

Тайм-аут запроса - через некоторое время пользователь может получить тайм-аут запросаТайм-аут сеанса - если методы хранения сеанса не используются, тайм-аут сеанса может возникнутьЗапросить блокировку потокапоскольку поток запроса не возвращается, он может заблокировать новые запросы (если достигнут предел пула)На некоторых серверах приложений состояние работоспособности сервера может вызывать принудительный перезапуск узла или приложения (из-за долго работающего потока запросов)Если пользователь покидает страницу:транзакция не отменена - в результате бесполезной обработки никто не выиграетпользователь не может вернуться, чтобы увидеть результаты после их завершениянет индикации прогресса - пользователь просто ждет обновления страницы

Есть несколько решений, которые я придумала, но я не уверена, что знаю, какие из них лучше (во всех аспектах: производительность, лучшая практика, элегантность и ремонтопригодность), и я хотела бы знать, какое решение рекомендуется, и если есть решение, которое я пропустил? (наверное да и много)

Плохое решение: использовать поток запросов в качестве рабочего потока, сохранять состояние прогресса в сеансе, вызывать вызов AJAX для проверки состояния (в сеансе) в другом запросе параллелизма

Компромиссное решениеСоздайте свой собственный пул потоков, обработайте поток мониторинга, рабочий поток и позаботьтесь о кластеризации, синхронизируя состояния либо в распределенном транзакционном кеше, либо в постоянном хранилище. это освобождает запрос, но создает потоки, о которых сервер приложений не знает, и не закрывается при отключении. Это зависит от вас, чтобы закрыть потоки в чистом виде, и всегда есть вероятность, что вы в конечном итоге что-то утечку. Это не J2EE способ сделать это.

Решение J2EE: используйте JMS для асинхронной задачи, вот для чего

Весеннее решение: использовать Spring Batch

Что бы вы делали / делали в своих проектах? Какие еще решения вы знаете? кто из тех, кого я отметил выше, по вашему мнению, победитель?

Ответы на вопрос(4)

Ваш ответ на вопрос