[ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-383: ----------------------------------- Session invalidation != application shutdown. I think this paragraph in the servlet spec exists because the containers are allowed to either persist the sessions and reuse them at a later restart OR to not use persistent sessions. In the later case the sessioncontexts need to get destroyed of course. I asked myself the same question when working on this in OWB. And the conclusio (after discussing with many other people) was that we should _strictly_ follow the Session listener. If he tells us to destroy the session then we also gonna kill this very sessioncontext. If not then nothing happens. What is the impact of evicting the session anyway? The most important is that the @PreDestroy method on @SessionScoped beans get called. But what if the server is clustered? If a single node goes down this doesn't mean that the users session is dead. It could have been survived on a memcached (and get picked up from other nodes if required). Or there might be node-pairing and the shutdown might be part of a 'ripple-restart'. In this case the session survives as well as it got replicated to the paired node. My conclusio of all those things was that @PreDestroy in any passivating bean is _not_ reliable anyway. What if the cluster goes down and the new application version is not able to deserialize the bean again? What if the time spent during shut down is too long and the server doesn't even bother to reload the session from disk again (as he knows it is already timed out). Or think about @ViewScoped beans in case JSF is configured to use client-side state saving. And the user just closes his browser ;) There are many similar cases where you cannot 100% rely on beans in passivating scopes to be cleaned up properly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)