I have a question to all having HFSJ 2ed in front of you and having better understanding of the answer to question no. 15 from the mock exam related to the chapter 6 (session management) - answer is at page 279.
I'd opt for answer E as well as for A and C. In my opinion both, HttpSessionAttributeListener.attributeRemoved and HttpSessionBindingListener.valueUnbound will be called when session is invalidated and attributes are removed from the session.
Can anyone explain me why "removing an attribute isn't tightly associated with a session timeout"?
According to spec: [HttpSession.invalidate()] Invalidates this session then unbinds any objects bound to it.
and unbinding is done through HttpSession.removeAttribute(String)
According to spec [HttpSession.removeAttribute(String)]: "After this method executes, and if the object implements HttpSession-indingListener, the container calls HttpSessionBindingListener.valueUnbound. The container then notifies any HttpSessionAttributeListeners in the web application."
Now, to the question. Why Can we rely on HttpSessionBindingListeren if it comes to session invalidation and at the same time we can not rely on HttpSessionAttributeListener.attributeRemoved
HttpSessionBindingListener interface is implemented by objects that want to be notified when they are bound to a session or unbound from a session when they bound or unbound to the session. HttpSessionBindingListeners implement the valueBound and valueUnbound methods.
For HttpSessionAttributeListener, the class that implements this interface must be specified in the Deployment Descriptor. Whenever any session attributes are added, removed and replaced, it will be notified. HttpSessionAttributeListeners implement the attributeAdded, attributeRemoved and attributeReplaced methods. A web application which has a HttpSessionAttributeListener would normally have one such listener which would handle all attributes and all sessions.
Conclusion: HttpSessionBindingListener deals with one session object and HttpSessionBindingListeners are unique to particular objects. If two classes of objects implement this listener, the implementations could be completely different. One class could implement an empty valueBound() method and the other class could implement a functional valueBound() method. If an object implements HttpSessionBindingListener, its valueBound and valueUnbound methods are only invoked when that particular object is bound to a session or unbound from a session.
Basically, HttpSessionAttributeListener is implemented by an object that is interested in receiving events from all the sessions belonging to the application, while HttpSessionBindingListener is implemented by the object attributes for the particular session to which they are added or removed.
Joined: Aug 17, 2007
Hello Sujitha Samikkannu,
thanks for the answer in the first place.
Your detailed description have clarified few of my doubts, but there are still few of them left unanswered (at least I can't find all the implications related to Session Management).
1. how can HttpSessionBindingListener.valueUnbound imply session invalidation? Isn't that true that HttpSessionBindingListener.valueUnbound is called whenever attribute is removed from the session? Isn't it called when session.removeAttribute is called? In that case, how can I distinguish between session invalidation and simple removal of the attribute?
2. Isn't that true that each time HttpAttributeListener is triggered I can get session ID which triggered the event? In that case each session can be easily tracked which makes the situation more or less similar to having attribute noticed by the HttpSessionBindingListener. I mean, we know which session has removed attribute/became invalidated.
The most important question is: how can I differ between session being invalidated and attribute being removed from the session when all I have is HttpSessionBindingListener.
[ August 11, 2008: Message edited by: kelahcim kela ] [ August 11, 2008: Message edited by: kelahcim kela ]