Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Concurrency of @ApplicationScoped JSF managed beans

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?

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?

like image 681
St.Antario Avatar asked Jan 26 '16 08:01

St.Antario


1 Answers

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

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.

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.

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.

like image 141
BalusC Avatar answered Oct 24 '22 04:10

BalusC