Hi, Craig. > -----Urspr�ngliche Nachricht----- > Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
