@ApplicationScoped JSF管理bean的并发性 [英] Concurrency of @ApplicationScoped JSF managed beans

问题描述

我使用Mojarra 2.2.12，在我们的项目中，我们有了一些 @ApplicationScoped bean。例如：

I'm using Mojarra 2.2.12 and in our project we've got a few @ApplicationScoped beans. For instance:

@ManagedBean
@ApplicationScoped
public class AppScopedBean{

    private int commonValueForClients;

    //GET, SET

    public void evalNew(){
        int newCommonVal;
        //Evaluation of the new value, doesn't depend on the commonValueForClients
        commonValueForClients = newCommonVal;
    }
}

我的问题是我们应该担心新的分配值？

My question is should we worry about visibility of the new assigned value?

我在规范，JSF基础结构必须同步访问 @ApplicationScoped bean字段。因此，特别是对于Mojarra 2.2.12，我们应该声明该字段为 volatile 还是同步访问它？

I couldn't find in the spec that JSF infrastructure must synchronize access to @ApplicationScoped bean fields. So, particularly for Mojarra 2.2.12, should we declare the field as volatile or synchronize access to it explicitly?

推荐答案

JSF会不同步对任何范围内的托管bean的任何访问。

JSF does not synchronize any access to managed beans in any scope.

这是您的责任。使用现有的并发/同步封装作为字段类型，例如 AtomicInteger ， ConcurrentHashMap ， Collections＃synchronizeList（） 等

That's your responsibility. Use existing concurrency/synchronization wrappers as field types such as AtomicInteger, ConcurrentHashMap, Collections#synchronizedList(), etc. Use volatile only as last resort if no such wrapper exist.

在应用程序作用域中绝对需要同步可变对象豆。在例如 HashMap ，否则您可能有风险卡住线程（100％CPU）。它在会话作用域bean中不那么严格，因为它们只有在最终用户在同一会话上打开多个HTTP连接时才会被并发访问，这将默认情况下只发生在两个物理上不同的浏览器实例被生成，但他们将依次默认已经不共享会话。所以这只会发生在机器人/黑客的情况下，因此，仍然强烈建议在会话作用域bean中照顾这一点。在查看作用域bean中几乎没有必要，因为ajax请求是按规范 a>排队，但在PrimeFaces中，它可以通过< p：ajax async =true> 关闭，您必须考虑视图范围bean。

Synchronization of mutable objects is definitely necessary in application scoped beans. In case of e.g. HashMap, you may otherwise even risk a stuck thread (100% CPU). It is less strictly necessary in session scoped beans as they will only be accessed concurrently when the enduser opens multiple HTTP connections on the same session, and this will by default only happen when two physically different browser instances are spawned, but they will in turn by default already not share the session. So it would only happen in case of robots/hackers and it's therefore still strongly recommended to take care of this in session scoped beans as well. It is nearly unnecessary in view scoped beans as ajax requests are by specification queued, but in PrimeFaces it can be turned off by <p:ajax async="true">, and you'd have to take that into account in the view scoped bean as well. It is totally unnecessary in request scoped beans.

如果你碰巧有CDI，你可以选择模仿EJB的 @Lock code>注释与自定义注释和CDI拦截器。这在Stephan Kintelius的博客中有详细说明： CDI的并发控制，巧合地在你的问题的前一天。请记住，JSF bean管理工具是根据JSF 2.3而不赞成使用CDI。另请参见备份bean（@ManagedBean）或CDI Bean（@Named ）？如果可以，请转到CDI，了解bean管理。

In case you happen to have CDI at hands, you could optionally also mimic EJB's @Lock annotation with a custom annotation and a CDI interceptor. This is detailed in Stephan Kintelius' blog: Concurrency control for CDI, coincidentally posted the day before your question. Keep in mind that JSF bean management facility is as per JSF 2.3 deprecated in favor of CDI. See also Backing beans (@ManagedBean) or CDI Beans (@Named)? If you can, move to CDI as to bean management.

这篇关于@ApplicationScoped JSF管理bean的并发性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！