hi edilmar, #1 timeout: the window-context is based on the std. cdi session-context and therefore all window-scoped beans get destroyed automatically once the corresponding session gets destroyed e.g. due to the session-timeout. scopes which are based on the window-scope (like the grouped-conversation scope) have the same behaviour in that area.
#2 limit and customizations: there is nothing like an inactive conversation (that isn't possible by definition). to avoid that you have too many window-slots (per default 64 window-slots per session are allowed) which contain e.g. conversations (of that window), you can configure a different max.-count via ClientWindowConfig#getMaxWindowContextCount (or config-key: deltaspike.scope.window.max-count - see JsfBaseConfig.ScopeCustomization.WindowRestriction.MAX_COUNT) or you introduce your own concepts via a custom WindowContextQuotaHandler. regards, gerhard http://www.irian.at Your JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces, DeltaSpike and OpenWebBeans 2015-06-11 22:03 GMT+02:00 Edilmar LISTAS <[email protected]>: > Hi, > > I have an webapp with this enviroment: Glassfish 3.1.2.2 + JSF 2.1.29 + > CDI/Weld 1.1.8 + DeltaSpike 1.3.0 (GroupedConversationScoped) + RichFaces > 4.5.5 + JPA 2.0 + Hibernate 4.2.7. > > I use GroupedConversationScoped in many places and I have the > following doubt: imagine the user enters in a JSF page with a > conversation. DS starts up automatically a new conversation > for this bean. Then, the user closes the browser. What happens > with the conversation previously opened? Does the App Server > (in my case Glassfish) at any time in the future (using for > example the timeout defined for the Session) that the session > (and also the conversation) is not valid anymore and destroy it? > > Is there some way to my webapp "to help" the App Server and destroy > the session/conversation earlier? > > My problem is not "just" one JSF page. The user has the ability to > enter in a JSF page, clicks a link or button to open other JSF > page in a new tab to complete previously needed data, using other > conversation (because it is not possible to use just one), close > this tab and continues in the first JSF page. And this situation may > occurs many times, because a complex data processing. Then, if > the user just "close the other tab", many "old conversations" are lost, > depeding on App Server to save the memory. > > I didn't find in GroupedConversationManager a way to check all the > conversations actually active (for ex. getListConversations()) nor > a way to setup a name/id for each conversation that would allow me > to think a management for this situation. > > Thanks for any idea... >
