anonymous wrote : | -> SESSION scope is never a good implementation unless you have a very good reason to go for, | | Yes, you shouldn't put data that doesn't need to be session scoped into the session. But if your spec says that you need session scope views then... Did you read my post carefully yet :) Common I did not say that I need all components in SESSION. anonymous wrote : neither a very long running conversation timeout or even set it to the same time-out as the HTTP session time out. Standard is 30 minutes, or at least most of my apps. | | | Sorry, I can't parse this. Can't see? Can you look at the conversation stack for a bunch of runaway conversations waiting to be closed? Hardware is cheap but never enough for a large user base environment. anonymous wrote : <core:manager concurrent-request-timeout="500" | conversation-timeout="#{session.timeout}" conversation-id-parameter="cid" | conversation-is-long-running-parameter="clr" /> I knew this and did even use Seam's API to control programmatically but this is not what I was talking about in my original post. A more elegant timeout that coordinates with http session timeout. anonymous wrote : Yes, if you want to hold open a view as long as the sesion is active, then you have to use the session to hold the data. A shorter-lived scope won't ever cut it here!I don't want to use conversational session scope, only conversational scope here or no conversation at all by setting the conversation on/off. Thanks anyway View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038129#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...