tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Software AG <>
Subject AW: AW: SessionListener does not get enough information
Date Wed, 26 Jun 2002 09:11:09 GMT
Hi, Craig.

> -----Urspr√ľngliche Nachricht-----
> Von: Craig R. McClanahan []
> Gesendet: Dienstag, 25. Juni 2002 18:34
> An: Tomcat Users List
> Betreff: Re: AW: SessionListener does not get enough information

> > I am not convinced that it makes sense to keep SessionID 
> and according
> > information inside the DB. Of what use is the session 
> attribute architecture
> > then? All that would happen is that I need a session to 
> somehow generate a
> > unique ID, and all information is then stored inside my DB. 
> That means I
> > reproduce all the session handling code.
> >
> Why?  The servlet container already computes a unique (within 
> the scope of
> a particular webapp) id for you, and makes it accessible.  
> Just save the
> session id in a separate column as you store the 
> session-related stuff in
> the database and you can do the delete I proposed later.

Right. The only thing used from the session api is to have a unique id. All
the rest (attributes, events) must be implemented over and over again. Was
that the thought when the api was designed? Get me right, I do not say it
would not work.
> > If that does not exist, does it harm to swap the few lines? 
> It would do so
> > much good for application programming..... And if not, it 
> might be nice to
> > split the event into session_will_be_destroyed and
> > session_has_been_destroyed. I bet a lot of listeners are 
> more interested in
> > the first.
> >
> Making this change would have a very adverse effect.  
> Consider what your
> "attribute removed" listener assumes it can do -- access 
> other things in
> the session, right?  But you'd get IllegalStateExceptions 
> now, because the
> session has already been invalidated.  That makes no sense at 
> all -- it
> should be called

I agree that after destruction a session is in a non-operative state. But
what if the event is fired BEFORE the session is destroyed? At that point in
time, the session is fully operational, and a listener can do whatever it
wants with the session. Obviously, adding new attributes would not last, as
the session is about to expire.
> Note that the same design pattern applies with servlet 
> context listeners
> -- at application shutdown, the context attributes are removed first,
> before contextDestroyed() is called.

Note that this design pattern has been discussed by the same people, and I
still think that it is desireable again to have a pre-shutdown event. All
operating systems will send a SIGTERM before a SIGKILL to allow an
application to peacefully shut down. Or have a look at Swing. Each
WindowListener will get a WindowClosing event before the window is actually
closed. At the WindowClosing event it is even possible to prevent the window
from closing - the reason might be invalid or unsaved data.

Taken this design pattern into the servlet api, I'd like to have a
pre-timeout event that allows an application to handle it's data before it
gets thrown away, and maybe even decide to not timeout this one session for
whatever reason.

What do you think?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message