In our JSF2 project on JBoss 7.1.1, we define a session timeout in the web.xml and it works just fine.
However, sometimes we're getting view expiration, leading to errors like this one even if the session is still alive:
javax.faces.application.ViewExpiredException: viewId:/... - View /... could
not be restored.
Where can we set the view timeout, like we did for sessions? Or is the view expiration caused by something else?
Another cause of ViewExpiredException is that too many logical views are been created in the session. The default limit is JSF implementation specific and every synchronous GET request on a particular view basically creates a new view. So, for example, when you use Mojarra (which has a default limit of 15) and start a browser session and open the same view in 16 different tabs and then submit a form in the 1st one, then you may get this exception as well. The limit is configureable with a JSF implementation specific context parameter, which is com.sun.faces.numberOfLogicalViews for Mojarra and org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION in MyFaces (defaults to 20).
This is however a very rare real world problem. If your webapp is really designed to be used this way (e.g. a social/community site which invites to being opened in multiple tabs, such as discussion forum or Q&A), then you might consider using client side state saving instead.
See also:
javax.faces.application.ViewExpiredException: View could not be restored
com.sun.faces.numberOfViewsInSession vs com.sun.faces.numberOfLogicalViews
Related
When I am creating a new session (or try to access from an other computer) in Vaadin Flow I get this error:
Can't move a node from one state tree to another
From this link, I read something about UI and getUIId().
However, I don't understand how I should change my application in order to fix the error.
As Denis mentioned in the forum post you linked, wrong scope sounds like the most likely culprit. In other words, you are trying to use the exact same component instance in two different UIs, when both UIs should have their own instance. It's not possible to use the same instance in two places at the same time.
You can find the documentation for Vaadin Spring scopes here: https://vaadin.com/docs/latest/flow/integrations/spring/scopes
One possible cause of errors such as that is that if you're storing a Component in a static variable. You shouldn't do that - a Component instance can only belong to a single UI. A single UI in turn (in practice) means a single browser tab.
Is it possible to access session attributes inside the Vaadin SessionDestroyListener ? Or is it called after session getting destroyed ?
How the call back order regarding to HttpSessionListener, before or after ?
While the session object is available by calling sessionDestroyEvent.getSession(), its state is CLOSING and all attributes have already been removed from it (rather simple to test this...).
EDIT
#Morfic is completely right, so he gets the credit: when in a SessionDestroyListener's sessionDestroy() method, the session's attributes are, indeed, still available (I was not careful in my tests; re-did them, using the latest Vaadin release, 8.0.4).
I'm building a profile page with update form. After submitting the form with new data and several page refreshes I see sometime new and sometimes old data. It depends on thread handling current request. One thread contains new data and another one old. NHibernate is configured using ThreadStaticSessionContext and NoCacheProvider. In Autofac UserStore, OwinContext.Authentication and UserManager are configured as InstancePerRequest.
I tried to change ThreadStaticSessionContext to CallSessionContext and it started working normally. So the question is: why it works(ThreadStaticSessionContext is preferable for multithread apps) and what negative effects can it bring?
Thanks!
ThreadStaticSessionContext is for long running processes such as windows services or windows apps. For web applications you want to be implementing Session Per Request. This is what the WebSessionContext is for.
I actually don't use any of the contexts and just wire it up myself. See my answer here for an example.
i have upgraded our application to SWF 2 and have implemented FMPC pattern. majority of our existing flow definitions doesn't have end-state, now using FMPC as described here, you can trigger commit by putting commit=true to your end-state. Example of our flow:
get form object
save details to db (we want to commit here)
fetch the same object with refreshed data
display to view
its currently working with previous SWF and just using Open Session in View pattern. but we imlemented FMPC to avoid any LazyInitializationException. Now what's happening is steps 1-4 is happening except that changes are not committed, so in the view, we don't see any changes. it seems difficult to add end-state at the middle just to commit to DB and also this means we need to add so many end-state, so my question is how to tell (SWF/FMPC) to commit "programmaticaly" without having to add the end-state tag. If you know better approach, please tell also. Thanks!
Spring Web Flows can have inheritance, so you can implement the end-state in your parent flow and then have it as a parent for all your flows.
I resolved my issue. I finally found out that indeed Hibernate is auto-committing all my read-write operations. The problem is when refreshing the object concerned which gave me the impression that there is no read-write done while in fact there is. Doing sessioFactory.refresh(object) instead of plain find() effectively fetched the updated data from the DB. I guess its because the hibernate session is still alive (due to FMPC) that's why doing "find" will retrieve from the hibernate cache while "refresh" means re-reading the data directly from underlying database. Please correct my analysis as necessary.
I've an MVC3 web app which uses the default "in process" session. I've the PRG pattern in place - that is while postback if my modelstate is invalid I store the model in TempData and redirect to the original get action. In the get action I fetch the model data (if it exists) and send to the view. I believe this is one of the basic aspects of MVC.
I've learned that TempData in background is a session variable which
is used in the PRG transition. What I need to know is whether it is
possible to have a conflict or cross refrencing - if I use something
like TempData["model"] in two pages and access the pages
simultaneously. Would that overwrite the common data in
TempData["model"] or is it safe if I use the same tempdata names in
two different pages.
And does it conflict with Session["model"] kind of data? I'm facing some unexpected session data corruption - possibly due to my internal code that resets the session data or something else. Is it possible that session data can corrupt partially? I mean Session["data1"] is ok but Session["data2"] is gone?
My users often use the web app for a long duration causing session timeout. I tried for the ASP.Net session state service for session but that caused performance issues because I store some heavy objects (via serialization) in session. So finally I was back to the original default in proces mode.
Pls share if you've had any similar experiences.
TempData by default uses SessionState and access to SessionState is by default exclusive. So, if you do two concurrent reuquests, one will have to wait for the other to release the SessionState lock.
TempData does not interfere with using SessionState directly.
As SessionState by default uses in-proc, it can be invalidated almost anytime.
You might want to have a look at http://brockallen.com/2012/06/11/cookie-based-tempdata-provider/