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

Question

这是问题所在

企业Web应用程序的用户正在执行导致长(非常长)数据库查询(或其他长处理密集型任务)的任务

问题:

• 请求超时 - 一段时间后用户可能会收到请求超时
• 会话超时 - 如果未使用会话保持方法,则可能发生会话超时
• 请求线程锁定
  • 由于请求线程没有返回,它可能会阻止新的请求(如果达到池限制)
  • 在某些应用程序服务器中,服务器的运行状况可能会触发强制重新启动节点或应用程序(由于长时间运行的请求线程)
• 如果用户离开页面:
  • 交易没有被取消 - 导致无用处理,没有人会受益
  • 用户完成后无法返回查看结果
• 没有进度指示 - 用户只是等待页面刷新

我想出了几个解决方案,但我不确定哪个更好(在所有方面,性能,最佳实践,优雅和可维护性),我想知道你推荐的解决方案是什么,如果有的话我错过了一个解决方案？(可能是的,很多)

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

折衷解决方案:创建自己的线程池,处理监视线程,工作线程,并通过同步分布式事务缓存或持久存储中的状态来处理群集.这会释放请求,但创建应用程序服务器不知道的线程,并且不会在取消部署时关闭.它取决于你以干净的方式关闭线程,并且总有可能你最终会漏掉一些东西.这也不是J2EE的方法.

J2EE解决方案:将JMS用于异步任务,这就是它的用途

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

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

Answer 1

我会把你所谓的"坏解决方案"和"j2ee解决方案"结合起来:

1. 原始UI线程将异步JMS消息发送到"后端"并返回.
2. 后端接收异步请求并对其进行处理.
3. 当在后端达到结果(或错误)时,它将返回到控制器层.
4. 仍在进行AJAX轮询或使用Bayeux/Cometed的UI接收并显示结果.

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

1. 创建一个具有SESSION的"AsyncManagerService"(AMS),甚至可以在APPLICATION范围内创建,这样所有线程都可以与同一个实例进行通信.
2. AMS保存一个地图,其中id为键,任何对象为value.
3. 在创建请求JMS消息时,生成唯一的随机密钥并将其NULL作为值放入消息的jmsCorrelationId以及映射中.也将该id传递给UI.
4. 只要地图中的值为,NULL就让UI线程使用先前生成的id轮询AMS .
5. 结果准备就绪后,让您的JMS接收器将其放入给定ID的AMS映射中.
6. 下一次UI线程轮询地图时,它将收到答案并停止轮询.

这很干净,很好地从任何具体领域中抽象出来.纯粹的技术解决方案.

即使您不喜欢轮询,HTTP在设计上也是无状态的,我认为这种方式轮询只能在明确定义的时间间隔内进行.

无论如何,我实现了一个完全符合这种模式的系统,它运行得很好......