企业Web应用程序的用户正在执行导致长(非常长)数据库查询(或其他长处理密集型任务)的任务
问题：
>请求超时 – 一段时间后用户可能会收到请求超时
>会话超时 – 如果未使用会话保持方法,则可能发生会话超时
>请求线程锁定
>由于请求线程没有返回,它可能会阻止新的请求(如果达到池限制)
>在某些应用程序服务器中,服务器的运行状况可能会触发强制重新启动节点或应用程序(由于长时间运行的请求线程)
>交易未被取消 – 导致无用的处理,没有人会受益
>用户完成后无法返回查看结果
我想出了几个解决方案,但我不确定哪个更好(在所有方面,性能,最佳实践,优雅和可维护性),我想知道你推荐的解决方案是什么,如果有的话我错过了一个解决方案？ (可能是的,很多)
糟糕的解决方案：将请求线程用作工作线程,在会话中保存进度状态,让AJAX调用检查另一个并行请求中的状态(在会话中)
折衷解决方案：创建自己的线程池,处理监视线程,工作线程,并通过同步分布式事务缓存或持久存储中的状态来处理群集.这会释放请求,但创建应用程序服务器不知道的线程,并且不会在取消部署时关闭.由你决定以干净的方式关闭线程,并且总有可能你最终会漏掉一些东西.这也不是J2EE的方法.
J2EE解决方案：将JMS用于异步任务,这就是它的用途
你会在你的项目中做什么/做什么？你知道其他什么解决方案？您认为上面提到的哪一个是赢家？
解决方法
>原始UI线程将“异步JMS”消息发送到“后端”并返回.
>后端接收异步请求并处理它.
>当后端达到结果(或错误)时,它将返回到控制器层.
>仍在进行AJAX轮询或使用Bayeux / Cometed的UI接收并显示结果.
诀窍是匹配请求/响应对.我会这样做：
>创建一个具有SESSION的“AsyncManagerService”(AMS),甚至可以是APPLICATION范围,以便所有线程都与同一个实例通信.
> AMS持有一个地图,其中id为键,任何对象为value.
>创建请求JMS消息时,生成唯一的随机密钥并将其放入消息的jmsCorrelationId以及映射中,并将NULL作为值.也将该id传递给UI.
>只要映射中的值为NULL,就让UI线程使用先前生成的id轮询AMS.
>当结果准备好后,让您的JMS接收器将其放入给定ID的AMS映射中.
>下次UI线程轮询地图时,它将收到答案并停止轮询.
这很干净,很好地从任何具体领域中抽象出来.纯粹的技术解决方案.
即使您不喜欢轮询,HTTP在设计上也是无状态的,我认为这种方式轮询只能在明确定义的时间间隔内进行.
无论如何,我实现了一个完全符合这种模式的系统,运行得很好……
