Me and my friends are working in a project and we are stuck with the following problem:
the result of request.getSession(false) is not returning "null" whenever the session is not present but it is properly rturning the session name when the session is present. The session name defers as it is dependent on the name of the user logged on. We want to check the null condition to know that the session is valid.
Deepti Gupta wrote:
the result of request.getSession(false) is not returning "null"
What is it returning? When you are expecting it to be null, and it is not null, try display the contents of the session and see if it came from previous session. The session may still be alive, although you did like close the browser.
Does this happen even on the very first transaction after you start the server?
public HttpSession getSession(boolean create)Returns the current HttpSession associated with this request or, if there is no current session and create is true, returns a new session.
If create is false and the request has no valid HttpSession, this method returns null.
public HttpSession getSession() Returns the current session associated with this request, or if the request does not have a session, creates one.
jinx riley wrote:what i am doing is...right now i am generating a session for a user only when he is logged in..!!
I think that you are using the wrong terms, and that is make this confusing. You do not "generate a session", the servlet container does that.
As I pointed out, the only activity you should be taking upon login is to record the logged-in status by placing a scoped variable into the session that is used to indicate this status.
on the home page in order to check if a session exists i use the method request.getSession(false) so that a new session is not generated.
Firstly, you should be doing nothing of this sort in the home page. Creating the token should take place in the login action, and checking for the token should take place in a servlet filter that operates orthogonally to any specific page or action.
Stop thinking about creating and destroying sessions. Just leave them be. Concentrate instead on simply using the existing session to store state.
That sounds like a reasonable idea. But just to repeat Bear's point, you should then be storing an instance of that User class in the session. Then the login and logout processes would simply modify those variables you mentioned.
I'll respectfully disagree. Unless there's business logic that necessitates persisting these states, recording logged-in state in the user class is needless and fragile. The very presence of a user in the session is enough to indicate logged-in state, and its absence logged out state. Why redundantly record the states in the user?
Redundant state == fragility as the states now need to be kept in synch.