据测试报告，如果响应的渲染速度不够快，有时可能会多次按下一个按钮，导致后端代码的多次调用，这是我们不想要的。
应用程序是使用Glassfish 3.1.1中的JSF 2.0的Java EE 6 Web Profile。
我想知道这应该如何正确处理，并想到了几个场景：
我的直觉是，最好的方法是让敏感的代码块原子化，但问题在于呈现正确的响应。
我该如何处理？
答案 0 :(得分：10)
提交应该在呈现响应时使用javascript禁用所有按钮。
这是以通用方式实施的最简单方法。如果您恰好使用<f:ajax>，则可以使用jsf.ajax.addOnEvent()以通用方式执行作业。另一种JavaScript方法是创建一种“加载”覆盖，它阻止UI，以便最终用户不再能够与底层页面交互。这基本上是一个绝对定位的隐藏<div>，它跨越整个视口，带有一些opacity（透明度）。您可以在提交时显示它并在渲染时隐藏它。此技术的关键字为"modal dialog"。面向UI的JSF组件库至少已经在它们的组合中具有这样的组件。例如。 PrimeFaces内<p:dialog modal="true"> <p:ajaxStatus>或<p:blockUI>
唯一的缺点是，如果客户端已禁用JS或不使用它，它将无法工作，因此不会阻止HTTP客户端双重提交。
会话范围中的一个标志，表示它已经处于活动状态，因此会跳过敏感代码，然后继续重新呈现上一次提交的响应。
这更多地称为"synchronizer token pattern"，并且spec issue 559已经为JSF请求了目前在2.2的目标票据，但似乎没有任何活动。检测和阻塞部分在技术上易于实现，但如果您希望最终用户最终检索由初始请求生成的响应，则不容易实现同步响应处理部分。异步响应处理很简单：只是不要指定要更新的任何组件，即清空PartialViewContext#getRenderIds()返回的集合。毕竟，这比使用JS禁用按钮或阻止UI更强大。
据我所知，Seam 2是唯一为此提供可重用的JSF组件的人<s:token>。但我必须承认，对于新的OmniFaces组件，这是一个有趣的想法。也许我会亲自看看它。
同步块延迟处理直到上一个请求完成。然后应检测到它已被处理并跳过。
这通常不容易实现，这需要更改所有操作方法以检查作业是否已完成。如果webapp在多个服务器上运行，它也将无法工作。同步器令牌比在调用操作方法之前执行更容易。同步器令牌也更便宜，因为您不会在队列中结束多个请求，这只会花费线程/资源。
使用其中一个“新”范围（如转换）来处理检测？
通过使用托管bean作用域无法解决此问题。托管bean作用域有不同的用途：bean实例的生命周期。
答案 1 :(得分：3)
正如Adrian所说，我也会使用BlockUI。 Primefaces有一个BlockUI component。当您通过ajax提交表单时，您还可以在请求期间使用叠加层。有关示例，请参阅Primefaces的Ajax Status。