session.invalidate() IllegalStateException - java

I'm trying to invalidate a session. When I call:
session.invalidate()
it throws
java.lang.IllegalStateException: getLastAccessedTime: Session already invalidated
Any idea why? I can see the session and it's values just before the invalidate line.

You can use an HttpSessionListener to understand where and when the Session is timing-out or getting invalidated before you call the invalidate yourself.

Related

what is __flexSession attribute in HttpSession

i want to know what is __flexSession attribute in httpsession. Working on an application front is flex, wildfly10 is application server and back end is java. HttpSession has an attribute with name of __flexSession, which has HttpFlexSession object.which seems clone of HttpSession.After invalidation of HttpSession whenever I invalidate HttpFlexSession I got this exception.
java.lang.IllegalStateException: WFLYCLWEBUT0001: Session KvLvpquLBKMYJ_APyZ6jzxhenh3cRIjoZtHkdAf3 is invalid at org.wildfly.clustering.web.undertow.session.DistributableSession.validate(DistributableSession.java:55)
at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttribute(DistributableSession.java:142)
at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122)
at com.os.sp.web.servlet.SessionInvalidateServlet.doPost(SessionInvalidateServlet.java:58)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
This problem is resolved
"__flexSession" is auto created attribute it contains a session which is replica of main session (parent session).
If you will invalidate the session it will automatically invalidate the session contain by "__flexSession" attribute.
If you will invalidate the session contain by "__flexSession" attribute it will invalidate its parent also.
It’s just a theory but the problem is how you can ensure both sessions are invalidated.
So to overcome this doubt solution is first of all isolate both sessions to each other than invalidate one by one as

What does tomcat do when session expires?

What does tomcat do when session expires?
Does it set the session object invalidated?
Does it unlink all references to the session object so that I may not be able to get the expired session object by calling request.getSession(false) ?
I'm using Servlet 2.5 spec. Thanks.
There is no internal session garbage collector thread. Session are removed during getSession() invocations.
If request.getSession() is invoked and the session is no longer valid (its idle time is greater than maxInactiveInterval) then internal expire() method will be called. This method removes session from the Manager and fires appropriate events on the HttpSessionListener.
One can manually invalidate the session using its invalidate() method, which is a wrapper for the expire().
Tomcat (and every other container) will call HttpSession.invalidate()
From the documentation:
Invalidates this session then unbinds any objects bound to it.
Afterwards, request.getSession(false) will return null.
Related:
Best Practice: Releasing and invalidating HTTP sessions

HttpSession in Grails Application

In my grails application running on tomcat 7, Somewhere I am invalidating the existing http session (session.invalidate()) and creating a new session (request.getSession(true)).
But my this new session is not getting reflected everywhere in grails application. Due to this I do get 'Session already invalidated'.
I don't want to do request.getSession() everywhere. I am just using 'session'.
Is there anything in Grails 1.3.7, so that this new session gets reflected every where in app.
Please let me know if you need more info.
Regards
Well, Grails holds the reference to a session object and every time you ask it for a session it returns the same reference.. so if you invalidate a session and then ask for the session it will return the same invalidated session, and cause 'session already invalidated' exception..
This should work for you..
Execute following line Just after you do session.invalidate
//Trick - so that grails doesn't use old invalidated session but rather create new.
GrailsWebRequest.lookup(request).session = null
After that you can use session just as you do normally.. you dont need to create a new session yourself
See this thread for internals

Should we reset the session variables to null on web application logout?

Httpsession is per browser.Ideally should we reset the session variables on logout otherwise it will always be available for that Browser even user login again.Is that correct?
You can just invalidate the session by calling HttpSession.invalidate() which will clear all the attributes as well as destroy the session itself.
You don't need to reset all session variables. You just need to call session.invalidate() and servlet framework will take care of the rest.

Open and close Hibernate session

This is how I get a Hibernate Session and create query.
HSession.getSession().createQuery("query here").executeUpdate();
AND
Critaria cr=HSession.getSession().createCritaria(..).. ;
HSession is where my Session factory is located and getSession() method returns a new session
(getSessionFactory().openSession();)
I want to know whether
After calling cr.list(); Is the session is still alive?
If alive, getting this criteria or executing a query way is not good? and
Creating a Session as
Session s=HSession.getSession();
s.createCriteria...
Is the way to use the session and close it using s.close(); ?
Yes, the session will be alive until you close it. You can perform multiple operations against a session, but only close() will close it.
In your case, it looks like the sessions are controlled by whatever HSession is. You'll need to look at that to see if any transactions are performed, how the sessions are managed, etc.
I read about this today ... it said "A Session is opened when getCurrentSession() is called for the first time and closed when the transaction ends."
So according to this: If you have a transaction wrapped around it (and you should have i guess) and call transaction.commit() ... the session is closed.
In your case it should still be open.
Please correct me if I'm wrong with this ... ! :)

Categories