tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: AW: AW: SessionListener does not get enough information
Date Wed, 26 Jun 2002 17:09:48 GMT
A pre-shutdown event (for both sessions and applications) seems sane
enough (although adding the new method to the corresponding interfaces
would break 100% of the existing listener implementation classes) -- the
best way to get it considered is to send mail to the Servlet Spec feedback
address:

  servletapi-feedback@eng.sun.com

Craig


On Wed, 26 Jun 2002, Software AG wrote:

> Date: Wed, 26 Jun 2002 11:11:09 +0200
> From: Software AG <sag@stark-verlag.de>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: 'Tomcat Users List' <tomcat-user@jakarta.apache.org>
> Subject: AW: AW: SessionListener does not get enough information
>
> Hi, Craig.
>
> > -----Urspr√ľngliche Nachricht-----
> > Von: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > 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?
>
> Hiran
>
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message