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

Reply via email to