Breaking the problem down, we have 3 different types of notifications emitted to servlet spec listeners as part of expiring a session: 1) HttpSessionListener.sessionDestroyed() 2) HttpSessionAttributeListener.attributeRemoved() 3) HttpSessionBindingListener.valueUnbound() The expiration-related notifications can be sent out for 3 reasons: 1) Application call to session.invalidate(). 2) Session expired by container background thread due to inactivity. 3) Session expired by deployer thread as part of undeploy. There are also 5 possible places on the cluster where the above can occur: 1) Node where the session is currently active (i.e. node that last handled a request for the session.) This node "owns" the session. 2) Node where the session has been active, but the client for whatever reason has failed over to a different, still running, node. 3) Node where data about the session is stored in the distributed cache (JBoss Cache) but where the session has never been instantiated locally. 4) Node where the session is no longer currently active, but where it at one time was, AND the node is now the "owner" of the session because the node where the session was last active is no longer alive. This is a special case of #2. 5) Node where data about the session is stored in the distributed cache but where the session has never been instantiated locally AND the node is now the "owner" of the session because the node where the session was last active is no longer alive. This is a special case of #3. In the above I introduce the concept of "ownership" wherein a node that "owns" a session *might* have special responsibilities with respect to invoking listener methods. Note that the servlet spec (SRV.10.7) states that "Distributed containers are not required to propagate either servlet context events or HttpSession events to other JVMs", so in all cases above I am totally about notifications arising due to local activity on a node, not due to remote activity. I am going to draw up a matrix of the above combinations, with alternatives for each slot, and see if from this a rational set of policies can be derived. Note that for any 4.x fix, the policies and related configuration will be very primitive (probably a couple simple boolean system properties). This matrix will be more to drive thinking about 5.x solutions, plus to surface any gotchas that might influence the more simple 4.x fix. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176265#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...