web-applications - Web应用程序中长时间运行的查询问题的解决方案(异步请求)

Question

这是问题所在

企业Web应用程序的用户正在执行导致长时间(非常长)数据库查询的任务(或其他需要大量时间处理的任务)

问题:

请求超时-一段时间后，用户可能会收到请求超时

session 超时-如果未使用任何 session 保持方法，则可能会发生 session 超时

请求线程锁定

由于请求线程未返回，因此它可能会阻止新的请求(如果达到池限制)

在某些应用程序服务器中，服务器的运行状况可能会触发节点或应用程序的强制重启(由于长时间运行的请求线程)

如果用户离开页面:

交易未取消-导致无用的处理，没有人将从

中受益

用户完成

后无法返回查看结果

没有进度指示-用户仅等待页面刷新

我提出了几种解决方案，但是我不确定我知道哪个更好(在各个方面，性能，最佳实践，优雅和可维护性)，我想知道您推荐的解决方案是什么，是否有我错过的解决方案？ (可能是，还有很多)

糟糕的解决方案:将请求线程用作工作线程，在 session 中保存进度状态，进行AJAX调用以检查另一个并行请求中的状态(在 session 中)

折衷解决方案:创建您自己的线程池，处理监视线程，工作线程并通过同步分布式事务性缓存或持久性存储中的状态来照顾群集。这会释放请求，但会创建应用程序服务器不知道的线程，并且不会取消部署而关闭线程。由您自行决定以干净的方式关闭线程，并且总是有机会最终泄漏某些内容。这也不是J2EE的方法。

J2EE解决方案:将JMS用于异步任务，这是要解决的问题

Spring解决方案:使用Spring批处理

您将在项目中做什么/做了什么？您还知道其他哪些解决方案？您认为我上面提到的哪一个是赢家？

Answer 1

我将结合您所谓的“不良解决方案”和“j2ee解决方案”:

原始UI线程将异步JMS消息发送到“后端”并返回。

后端接收异步请求并对其进行处理。

在后端中达到结果(或错误)时，它将返回到 Controller 层。

UI仍在进行AJAX轮询或使用Bayeux/Cometed，接收并显示结果。

诀窍是匹配请求/响应对。我会这样:

创建一个具有SESSION甚至是APPLICATION范围的“AsyncManagerService”(AMS)，以便所有线程都与同一实例通信。

AMS包含一个以id为键，任何对象为值的 map 。

创建请求JMS消息时，生成一个唯一的随 secret 钥，并将其放入消息的jmsCorrelationId以及映射中，并以NULL作为值。并将该ID传递给UI。

只要 map 中的值为NULL，就让UI线程使用先前生成的ID轮询AMS。

结果准备好后，让您的JMS接收器将其放入给定ID的AMS映射中。

下次UI线程轮询 map 时，它将收到答案并停止轮询。

这是干净的，并且可以从任何具体域中抽象出来。纯粹的技术解决方案。

即使您不喜欢轮询，HTTP在设计上也是无状态的，我认为这种轮询仅在定义良好的时间间隔内进行。

无论如何，我用这种模式实现了一个系统，并且运行得很好。。。