Pinghua Young wrote:

> Craig, thanks for your responses!  In one of your later messages, you
> mentioned you have designed an admin app so that a user's session
> can be terminated.  I wonder how you did that.
>
> Right now, what I did is:
>
> #1.  Create a static hashtable (indexed by userID) in my base servlet;

Is there a particular reason you chose a static variable instead of an instance 
variable?  Statics
can get you in trouble if you are running more than one application in the same server 
that uses
the same base servlet class.  If your base servlet does not implement 
SingleThreadModel, you can
count on there being a single instance (per application), unless you're using a 
distributed server
type environment (in which case static won't help you either).

>
> #2.  Put the session into this hashtable when user logins;

Because it's keyed by user id, I assume you've got a restriction that no simultaneous 
logins are
allowed, right?

>
> #3.  Then I can clear the user's session from my admin servlet if given a valid 
>userID;

Don't forget to clear the entry if the user's session times out, or the user executes 
your normal
"logout" action.

>
> The problem I have is this: if the web server gets restarted, then
> my hashtable will be gone, but the existing users' sessions are still
> active, and I can't clear them because my hashtable doesn't have
> their references anymore.  Now even if I serialize out my hashtable
> to disk and read it back in when server restarts, I don't think they
> will contain references to the same sessions.  Am I right?
>

When a session stops existing is sort of a metaphysical question :-).

If your servlet engine does not support session persistence across server restarts, 
then all
sessions that were active at the moment the server was restarted are no longer valid.  
The browser
will still pass in a session ID cookie (or a URL with an encoded session ID) for the 
old session
ID, but that won't be recognized as valid by the engine.  Thus, saving references to 
the old
session objects won't do you any good.  This is pretty much the same thing that 
happens when a
session times out -- the browser doesn't know that, so it still asks for the old 
session, but the
server no longer recognizes the requested ID as valid.

If you want sessions (and presumably the user data objects stored in them) to survive 
a web server
restart, you need to use a servlet engine that supports this.  There will also be 
restrictions on
the kinds of objects you can store in such a sesssion -- such as the requirement that 
they must
implement Serializable.


> Thanks!  --Pinghua
>

Craig

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to