I've been developing an online tutor using servlet/JSP technology, and have been having problems with invalidating my HttpSession. Basically, it doesn't seem to go away when I tell it to. I've tried to narrow the problem down, and I now have a skeleton app where I don't explicitly create an HttpSessions.
I've been developing an online tutor using servlet/JSP technology, and have been having problems with invalidating my HttpSession. Basically, it doesn't seem to go away when I tell it to. I've tried to narrow the problem down, and I now have a skeleton app where I don't explicitly create an HttpSession.
What seems to be happening is that if I call this nethod twice , the first time through it outputs "No session id", but the second time (and all subsequent times) it outputs the session id. This suggests to me that the geRequestDispatcher method is creating a session, and I suspect that this may be behind my problems.
Do any more experienced members have any suggestions? Is this really causing my problems with session.invalidate(), and if so how can I fix it.
I don't quite understand why it wasn't being called - all my other Action classes return the name of a jsp file to my controller and work fine, but my LogoutAction class returned the name of an html file. When I changed that to make it return a jsp, it started working.
On the bright side, I think I understand sessions a little better now. I do have one question - what does the container do to sessions when it invalidates them? Does it just remove the ID and make it available for garbage collection?
what does the container do to sessions when it invalidates them?
Based on the way the HttpSessionBindingListener is defined, it appears that when invalidating a session the server looks at each bound object as it is removed from the session. If that interface is implemented, the valueUnbound method is called.
There are other session related interfaces that must be satisfied also, so it looks like session invalidation can cause a lot to happen.
The other interesting thing about sessions that I found - well, it was interesting to me anyway - is that they can be created when you run a jsp file. This caused me a lot of confusion at first, as I was finding sessions already in existence before I had explicitly created then in my servlet code.
It wasn't until I looked at the _jsp.java files that I saw what was going on.
You could however use the isNew() method on the session object to check if its a new session.
Yes, that's exactly what I did. The first time I explictly created a session, I tested it with the isNew() method and found that the session was not new. It turned out that I had already run a jsp file, and that the jsp code had already created a session.
Here's a code snippet from the java file generated from the jsp.
Maybe the lesson is to make sure I generate my sessions before running any jsp files, or at least be aware of what's going on if I run the jsp files first.
Why am I being picky? Because the words you use to describe some action influence how you think about the action. For example, the continued difficulty new Java programmers have in distinguishing between creating an object and creating a reference to an object.
Originally posted by William Brogden:
<ExcessivelyPickyMode>You dont "run" a JSP file, you execute a servlet created automatically from a JSP file by the JSP translate - compile mechanism.</ExcessivelyPickyMode>
I don't think it is being picky at all. It is important to realize that a JSP is, in essence, a servlet.