So, from reading that and judging from the fact that the servlet spec has no details on how these events should behave in a cluster, I think that we should support the different scenarios and allow people to configure what happens. There's a case to be made for most of the possibilities I think.
On 11 Dec 2007, at 00:57, Tim Eck wrote: > I guess no one wants to bite on this on, too bad. > > I happened to stumble into this thread. I guess Kunal is talking to > him, > presumably because he is unhappy with Resin's handling of session > events > in the cluster. > > http://www.nabble.com/Why-is-session-unbound-called-after-cluster-failover > --to13505639.html > > I also learned from that thread that Tomcat has a feature where you > can > have it run the events on all nodes (at least I think that is what it > does, I didn't try it) > > (search for notifyListenersOnReplication, etc) > http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html > > -tim > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:tc-dev- >> [EMAIL PROTECTED] On Behalf Of Geert Bevin >> Sent: Thursday, December 06, 2007 3:34 PM >> To: [email protected] >> Subject: [tc-dev] Where to execute HttpSessionBindingListener events? >> >> Hi all, >> >> I'm writing this email to get some input. >> >> For the distributed HTTP sessions chapter of the book I was proudly >> writing about session attribute events being properly clustered, >> since >> Terracotta doesn't only cluster data ... until ... I tried out my >> example in the sessions configurator and found out that it didn't. >> I've been talking this over a bit with Tim, and we'd like to get some >> more gray cells working on this ;-) >> >> So, the contract of HttpSessionBindingListener is that when an >> attribute value implements it, the valueBound method is called at >> session.setAttribute and before session.getAttribute is able to >> provide this attribute value. The valueUnbound is called after >> session.getAttribute stops providing it. >> >> Many of the examples online that use HttpSessionBindingListener, use >> it for cleaning up resources like JDBC connections. That's why >> assumed >> that the node that bound a session attribute value would also be the >> node that unbinds it. Hence allowing system-level resources to be >> properly cleaned up. Currently, this isn't the case. The valueBound >> and valueUnbound methods both called on the node where the session >> activity is taking place (like setAttribute). Tim makes a good point >> however in that the node that bound the value could not exist >> anymore, >> so that there should be some special handling for that. Personally, I >> see the valueUnbound method as a DMI that should be executed on all >> nodes that have a reference to the session with the attribute. >> >> What do you guys think? Should this behavior change to distribute the >> events over the cluster, or should it just stay as it is? >> >> Thanks for your thoughts about the issue. >> >> Geert >> >> -- >> Geert Bevin >> Terracotta - http://www.terracotta.org >> Uwyn "Use what you need" - http://uwyn.com >> RIFE Java application framework - http://rifers.org >> Music and words - http://gbevin.com >> >> _______________________________________________ >> tc-dev mailing list >> [email protected] >> http://lists.terracotta.org/mailman/listinfo/tc-dev > -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
