Lifecycle of UI, VaadinServiceSession, and HTTP Session

Hello,

I’m confused about the lifecycle of UI, VaadinServiceSession, and HTTP Session.

While trying to update my spring integration, I encounter that the UI lifecycle is mysterious to me: when I use the vaadin7 UI, the UI instance stays the same, but when I use the browser refresh button, the UI instance changes (and yes, this also implies that the life time of UI is shorter than that of the HTTP session). In addition, the now superfluous old instance (from before refresh) get closed/gc’ed at some random time after refresh.

For proper Spring UI lifetime integration, I’m also missing a hook to when a new UI instance is constructed.

Last no least, in the ‘Vaadin7 beta 3 released’ forum thread, the new VaadinServiceSession is mentioned that is ‘per servlet (i.e. VaadinService) instead of one shared VaadinSession for all servlets’. How does this relates to the ‘real’ HTTP Session?

Cheers,

aanno

Well, this was a valid question and now I’m able to answer it myself. The lifecycle is discussed in some detail in the
ticket for implementing VaadinServiceSession
.

Also, having a new UI each time you hit the refresh button of the browser seems to be an expected behaviour in vaadin7 - but if you don’t like it, there is the @com.vaadin.annotations.PreserveOnRefresh annotation. I just don’t understand if there is a price to pay if you use it (hint: a small explanation in javadoc would be in order).

To summarize: With vaadin7, you get 2 more ‘scopes’ of your web application: The VaadinServiceSession is associated with the lifetime of HttpSession. It is independant of the HttpSession in the sense that different Servlets would share the (same) HttpSession, but they will have different VaadinServiceSessions.

In addition to that there is the UI scope. This scope is ‘embedded’ in a certain VaadinServiceSession but could be shorter. For example, if you refresh your browser, you get a new UI (scope) and the old will be discarded at some point in the future. I have not fully understood what is the exact reason for this scope, but I expect it to be a mean to make (browser) multitab application possible that don’t share state.

When I’m using beta3 at present, there is one nasty glitch: The VaadinServiceSession will get invalidated very soon (5 minutes of browser inactivity or so). Does someone know if there is a knob to tweak this?

Seems related to heartbeat intervall:
RE: Vaadin 7 - reliable close detection?
and
DeploymentConfiguration

Cheers,
Christian

The reason for changing the default from how Vaadin 6 worked is mainly related to usability - users generally expect things to be reloaded (e.g. reading fresh data from the database) when reloading the page in the browser which wouldn’t happen if the previously used UI instance would be reused.

The only price you pay for using PreserveOnRefresh right now is a very minor increase in memory usage (for mapping the window.name to the UI instance bound to that browser window). The other quite theoretical price is that a future version of Vaadin could provide mechanism for starting the UI slightly faster by choosing to leave out the second server round trip that is now used for making e.g. the URI fragment available in UI.init but is also required to make @PreserveOnRefresh work.

The reasons are for supporting multitab application without nasty synchronization of the same UI state among multiple tabs as well as the usability aspects related to refreshing the UI when the browser tab is reloaded by the user.

You can define the duration of a session (in minutes) in the web.xml:

<session-config>
      <session-timeout>1</session-timeout> 
</session-config>

I wonder if this pair of getter-setter methods on the

WrappedSession

class are a programmatic way to set the timeout programmatically (and dynamically) rather editing that config file?

Seems that we can reach that object by:

VaadinSession.getCurrent().getSession().setMaxInactiveInterval(5*60);

(but I’ve not tried that code)

–Basil Bourque