Menu
I've been googling for a couple hours on this issue to no eval.
WELD docs and the CDI spec are pretty clear regarding thread safety of the scopes provided.
For example:
Application Scope - not safe
Session Scope - not safe
Request Scope - safe, always bound to a single thread
Conversation Scope - safe (due to the WELD proxy serializing access from multiple request threads)
I can't find anything on the View Scope defined by JSF 2.x.
It is in roughly the same bucket as the Conversation Scope in that it is very possible for multiple requests to hit the scope concurrently despite it being bound to a single view / user. What I don't know is if the JSF implementation serializes access to the bean from multiple requests.
Anyone have knowledge of the spec or of the Morraja/MyFaces implementations that could clear this up?
414
Once the user has navigated into another view the viewscoped bean goes out of scope. If your application has a page has been getting re displayed, then you can put the data for this page into view scope, thereby reducing the size of the session scope. You can put the managed bean in the view scope using the @ViewScoped annotation.
But it bears a high potential for undesired behavior, which is mostly not noticed until real problems arise. Problems caused by wrong Bean Scopes are often hard to trace and require profound knowledge of the JSF framework (and the fundamental principles of web applications in general).
In the previous releases of jsf and before jsf 2 coming into existence, the managed beans were defined by providing the <managed-bean/> xml fragment into the jsf configuration file (faces-config.xml), but since jsf 2 the managed beans are defined using the old one and using a new fashion way, through the using of annotations.
The @ViewScoped has been introduced by JSF 2.0 specification. In a nutshell the data which is @ViewScoped will keep living as long as you don’t navigate to another pagee to itself.
The view scope is with normal usage thread safe. It can be used by only one browser window/tab. Namely, it's keyed by an unique hidden input field which is set on the initial GET request. Every postback on the same view will use the one and same view scoped bean. The browser itself already "synchronizes" postback requests in the same window/tab. A new browser window/tab is effectively a new GET request and will therefore create a new and completely independent view.
As to ajax postbacks, they are by specification queued. This is mentioned in chapter 13.3.2 of the JSF 2 specification:
13.3.2 Ajax Request Queueing
All Ajax requests must be put into a client side request queue before they are sent to the server to ensure Ajax requests are processed in the order they are sent. The request that has been waiting in the queue the longest is the next request to be sent. After a request is sent, the Ajax request callback function must remove the request from the queue (also known as dequeuing). If the request completed successfully, it must be removed from the queue. If there was an error, the client must be notified, but the request must still be removed from the queue so the next request can be sent. The next request (the oldest request in the queue) must be sent. Refer to the
jsf.ajax.requestJavaScript documentation for more specifics about the Ajax request queue.
Only when using PrimeFaces, queueing can be disabled with <p:ajax async="true">. When using this in combination with view scoped beans, threadsafety must be reconsidered the same way as for session scoped beans.
142
ViewScoped beans are stored in a "view" Map that is created for every UIViewRoot. When two concurrent requests are processed by a JSF runtime, usually, it is unlikely that the same UIViewRoot instance is created/restored for these requests, as the javax.faces.ViewState form parameter in the HTTP request is used to determine whether an existing UIViewRoot instance should be restored or not (on postback). As BalusC has indicated, two different browser windows will result in two different view scoped beans being created, as the underlying ViewStates parameters are different for both the browser tabs (if you are issuing two different HTTP requests and the browser is using the response of each to display the individual tabs, instead of using a cached copy).
The part about thread-safety however goes beyond browser tabs/windows. There is no inherent mechanism within the JSF runtime (atleast within Mojarra) that will synchronize access to the UIViewRoot and the view map, if two HTTP requests (and hence, two threads) present the same javax.faces.ViewState value in the request to be processed by the container. Hence, view scoped beans are not threadsafe by nature, and neither are they accessed in a thread safe manner. You could confirm this by replaying requests with the same javax.faces.ViewState values and observe the behavior of the container/JVM when multiple such requests are received by the container in a short duration (resulting in the possibility of concurrent access to the same UIViewRoot instance by multiple threads).
41
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
