并发请求超时参数或避免并发访问会话异常的选项的实用价值 [英] Practical value for concurrent-request-timeout parameter or options for avoiding concurrent access to conversation exception

问题描述

在《 Seam参考指南》中，可以找到以下段落:

In the Seam Reference Guide, one can find this paragraph:

我们可以在components.xml中为并发请求超时(以毫秒为单位)设置合理的默认值:

We can set a sensible default for the concurrent request timeout (in ms) in components.xml:

<core:manager concurrent-request-timeout="500" />

但是，我们发现在大多数情况下，尤其是在对话访问中存在严格的限制接缝的情况下，500 ms的时间不足以应付我们要处理的大多数情况.

However, we found that 500 ms is not nearly enough time for most of the cases we had to deal with, especially with the severe restriction seam places on conversation access.

在我们的应用程序中，我们结合了页面范围内的ajax请求(由各种用户操作触发)，一些全局范围内的轮询通知逻辑(标头的一部分，因此包含在每个页面中)以及调用操作和/或常规链接的常规链接导航到其他页面.

In our application we have a combination of page scoped ajax requests (triggered by various user actions), some global scoped polling notification logic (part of the header, so included in every page) and regular links that invoke actions and/or navigate to other pages.

因此，即使站点上没有任何重大负载，我们也经常获得对会话异常的可怕并发访问.

Therefore, we get the dreaded concurrent access to conversation exception way too often, even without any significant load on the site.

在研究了很多选项之后，我们最终将此值提高到几秒钟(我们正在讨论是否将其提高到10s)，因为没有推荐的解决方案似乎无法完全解决我们的问题(甚至将所有ajax请求强制设置为全局队列仍会使我们面临用户决定在我们的一个轮询呼叫正在进行时单击链接的权利).而且，我们宁愿让用户等待一两秒钟，而不是仅仅因为他们在错误的时刻单击了链接而获得错误页面.

After researching the options for quite a bit, we ended up bumping this value to several seconds (we're debating whether to bump it up to 10s), as none of the recommended solutions seemed able to solve our issue completely (even forcing a global queue for all the ajax requests would still leave us exposed to a user deciding to click a link right when one of our polling calls was in progress). And we'd much rather have the users wait for a second or two instead of getting an error page just because they clicked a link at the wrong moment.

现在要提出的问题是:我们是否缺少某些明显的东西(例如允许并发访问对话并照顾所需的锁定自己的方法，例如:)?人们如何解决接缝中的这个问题(ajax请求与用户驱动的交互混合在一起)?在进行ajax请求时(如一个博客页面所建议的那样)，禁用页面上的所有链接实际上是不可行的.

And now to the question: is there something obvious we're missing (like a way to allow concurrent access to conversations and taking care of the needed locking ourselves, for instance :)? How do people solve this problem (ajax requests mixed with user driven interaction) in seam? Disabling all the links on the page while ajax requests are in progress (as suggested by one blog page) is really not a viable option.

还有其他建议吗?

TIA， 安德烈(Andrei)

TIA, Andrei

推荐答案

我们使用60000或120000(1-2分钟).并发请求超时旨在避免死锁.从历史上看，超时问题比僵局问题要多得多.更好的方法是使用客户端队列(如果使用RichFaces，则使用<a4j:ajaxQueue>)来尽可能地序列化和删除重复的请求，然后将超时设置得足够高以避免任何剩余的问题.

We use 60000 or 120000 (1-2 minutes). Concurrent-request-timeout is designed to avoid deadlocks. Historically we have far more problems with timeouts than deadlocks. A better approach is to use a client-side queue (<a4j:ajaxQueue> if using RichFaces) to serialize and remove duplicate requests as much as possible, then set the timeout high enough to avoid any remaining problems.

Seam的并发请求超时导致许多严重的问题:

There are many serious issues resulting from Seam's concurrent request timeouts:

• 问题是最后请求获得了ConcurrentRequestTimeoutException.如果用户双击或重新加载页面，则仅 last 请求很重要-为什么他会收到错误消息?
• 通常，ConcurrentRequestTimeoutException被抑制，并且仅显示次要NullPointerExceptions和@In注入失败，从而使调试变得困难.
• 接缝2.2.1有一个严重的问题，在发生超时之后，事务，ThreadLocals和锁可能泄漏，尤其是与<spring:spring-transaction/>一起使用时.看SeamPhaseListener.afterRestoreView:restoreConversation失败后没有要清除的finally块！

• The issue is the last request gets the ConcurrentRequestTimeoutException. If the user double-clicks or reloads the page, only the last request matters -- why should he get an error?
• Usually the ConcurrentRequestTimeoutException is suppressed, and only secondary NullPointerExceptions and @In injection failures are shown, making debugging difficult.
• Seam 2.2.1 has a severe problem where transactions, ThreadLocals, and locks may leak after a timeout occurs, especially when used with <spring:spring-transaction/>. Look at SeamPhaseListener.afterRestoreView: there's no finally block to clean up after restoreConversation fails!

我认为此设计有很多不良方面，因此最好使用更长的超时时间并尝试避免出现问题.

In my opinion there are many poor aspects to this design, so it's best to use a much higher timeout and try to avoid the issues.

这篇关于并发请求超时参数或避免并发访问会话异常的选项的实用价值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！