Thanks Robert:

This is great information.

I was curious if the beans in the timed-out session automatically get
descoped and garbage-collected?

thanks,
Theron



                                                                                       
                
                    Robert Nocera                                                      
                
                    <rnocera@neos        To:     Struts Users Mailing List             
                
                    llc.com>             <[EMAIL PROTECTED]>              
                
                                         cc:                                           
                
                    03/20/02             Subject:     RE: Questions about session 
timeouts/struts      
                    09:52 AM                                                           
                
                    Please                                                             
                
                    respond to                                                         
                
                    Struts Users                                                       
                
                    Mailing List                                                       
                
                                                                                       
                
                                                                                       
                



If the session times out or is invalidated, you will no longer be able
to access the same session using request.getSession().  Any session you
do access will be a new instance.  This means that any objects in the
session are probably not accessible to your application any longer.

You can implement HttpSessionBindingListener on a bean that you store in
session and then implement the valueUnbound method to do something when
your bean is removed from the session.

This worked for me in Tomcat and let me know when a session was being
timed out, but I found that other application servers, such as
SilverStream, do not behave the same way. The session times out, but the
beans are not unbound and so the method is never called.  From the spec
I don't think invalidating a session requires beans to be unbound if it
does, I think it is a bug in SilverStream's implementation.

Hope this helps,

Robert Nocera
New England Open Solutions
www.neosllc.com
"You supply the Vision.  We will do the rest."



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 12:27 PM
To: Struts Users Mailing List
Subject: Questions about session timeouts/struts


Hi Folks:

Don't really know much yet about this...    I've implemented
sensitive-form
resubmissions by way of tokens within actions but have a question about
when a session times out...

Under Apache (I don't know where yet), I suspect there's a
timer/variable
in some configuration file that says how long a session bean is valid
without any hits before it times out.    I also think one can call
explicity "request.getSession().invalidate()" which does the same thing
but
affects all session beans....

So here's my question(s):
- Anyone have any advice on how to deal with this programatically?
- When session beans do "timeout" or become "invalid", are they
automatically cleaned up by the system?    So in essance if I have a
bean
called "fooBean" that I added via (request.getSession().setAttribute
("fooBean", fooBeanInstance)   AND if the session automatically times
out
(without me calling request.getSession().removeAttribute("fooBean")),
does
the tomcat contain remove "fooBean" from the session scope or will it
still
be there if I call "request.getSession().setAttribute("fooBean")"....

I'd like to understand a little bit more on how best to handle/deal with
situations where the session becomes invalid() or times out.   What
happens
to all the beans/data contained for that session.    With struts, do all
formbeans with session scope become defunct?

thanks,
Theron


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to