The events on the previous page are for key moments in the life of the session. But the HttpSessionBindingListener is for key moments in the life of a session attribute. Remember from Chapter 5 where we looked at how you might use this—if, for example, your attribute wants to know when it’s added to a session so that it can synchronize itself with an underlying database (and update the database when it’s removed from a session). Here’s a little review from the previous chapter:
You do NOT configure ALL session listeners in the DD!
If an attribute class (like the Dog class here) implements the HttpSessionBindingListener, the Container calls the event-handling callbacks (valueBound() and valueUnbound()) when an instance of this class is added to or removed from a session. That’s it. It just works. But this is NOT true for the other session-related listeners on the previous page. HttpSessionListener and HttpSessionAttributeListener must be registered in the DD, since they’re related to the session itself, rather than an individual attribute placed in the session.
Remember from the previous chapter, we talked briefly about distributed web apps, where the pieces of the app might be replicated across multiple nodes in the network. ...