[jboss-jira] [JBoss JIRA] Commented: (JBAS-5778) Improve HttpSessionListener handling in clustered environment

[Jimmy Wilson (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBAS-5778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12434767#action_12434767 ] 

Jimmy Wilson commented on JBAS-5778:
------------------------------------

This JIRA introduces the concept of a clustered session notification policy for determining whether the servlet spec notifications related to session events are allowed to be emitted on the local cluster node.  Such notifications are emitted to implementations of the javax.servlet.http.HttpSessionListener, javax.servlet.http.HttpSessionAttributeListener, and javax.servlet.http.HttpSessionBindingListener interfaces.

This new notification policy concept is defined in the org.jboss.web.tomcat.service.session.notification Java package, and all classes referenced below are a part of this package.

While it is possible to implement ClusteredSessionNotificationPolicy for case-specific customization, JBoss provides LegacyClusteredSessionNotificationPolicy, which implements the behavior in previous JBoss versions (the default), and IgnoreUndeployLegacyClusteredSessionNotificationPolicy, which implements the same behavior except for undeployment situations in which no HttpSessionListener and HttpSessionAttributeListener notifications are sent.

It is possible to change from the default LegacyClusteredSessionNotificationPolicy to IgnoreUndeployLegacyClusteredSessionNotificationPolicy or to a custom ClusteredSessionNotificationPolicy implementation by performing one of the following steps:

* Using the system property 'jboss.web.clustered.session.notification.policy' and setting it equal to the class name of the policy you want to choose.  This will change the policy for all web applications deployed in the application server.
 
* Using jboss-web.xml to set the policy per application using the following format:
 
  <replication-config>
     <session-notification-policy>
        CLASS-NAME-HERE
     </session-notification-policy>
  </replication-config>

Please note that the session-notification-policy element shown above is not part of the official DTD for a JBoss 4.2+ jboss-web.xml (see http://www.jboss.org/j2ee/dtd/jboss-web_4_2.dtd). However, the internal jboss-web.xml parsing logic will properly handle the element in JBoss AS 4.2.4 and later as well was in EAP 4.2.0.GA_CP05 and 4.3.0.GA_CP03 and 
later.

For JBoss 5.0.0.GA and later, the session-notification-policy element is part of the JBoss 5 version of the jboss-web.xml DTD.

> Improve HttpSessionListener handling in clustered environment
> -------------------------------------------------------------
>
>                 Key: JBAS-5778
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5778
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.2.0.GA, JBossAS-4.2.1.GA, JBossAS-4.2.2.GA, JBossAS-4.2.3.GA
>            Reporter: Takayoshi Kimura
>            Assignee: Brian Stansberry
>
> Suppose we have a web application which uses stateful session beans, and we have a HttpSessionListener like this:
> public void sessionDestroyed(HttpSessionEvent event) {
>     event.getSession().getAttribute("sfsb").remove(); // Make sure to call SFSB's @Remove method
> }
> This behavior is what Seam does.
> The HttpSessionListener.sessionDestroyed() would be called in session invalidation, session timeout and during undeploy/shutdown for cleaning up local resources. This happens in both cases, clustered and non-clustered .
> However, in clustered environment, the sfsb.remove() method call in HttpSessionListener becomes a cluster-wide operation. So when we shutdown one node, HttpSession is still available on the other node for fail over but SFSB is missing. As a result we will get javax.ejb.NoSuchEJBException: Could not find stateful bean.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira