On Tue, 25 Jun 2002, Software AG wrote:
> Date: Tue, 25 Jun 2002 10:47:14 +0200
> From: Software AG <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: 'Tomcat Users List' <[EMAIL PROTECTED]>
> Subject: AW: SessionListener does not get enough information
>
> Hi, Craig.
>
> 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.
> Maybe I missed something in the servlet spec 2.3, but can you please point
> me to the section that says something like ...session attributes must be
> deleted before the "session destroyed" event is fired...?
>
Rats ... all I've got are my notes of discussions with the spec lead where
this was the intended behavior; it wasn't spelled out specifically. I
will add this to the list of stuff that needs to be clarified in 2.4
(which should go into public review shortly).
> 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
Note that the same design pattern applies with servlet context listeners
-- at application shutdown, the context attributes are removed first,
before contextDestroyed() is called.
> Hiran
>
Craig
>
> > -----Ursprüngliche Nachricht-----
> > Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Gesendet: Montag, 24. Juni 2002 18:28
> > An: Tomcat Users List
> > Betreff: RE: SessionListener does not get enough information
> >
> >
> >
> >
> > On Mon, 24 Jun 2002, tamir wrote:
> >
> > > Date: Mon, 24 Jun 2002 14:54:00 +0200
> > > From: tamir <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > > To: 'Tomcat Users List' <[EMAIL PROTECTED]>
> > > Subject: RE: SessionListener does not get enough information
> > >
> > > Hi Hiran,
> > > I just bugged into this problem yesterday. I don't
> > understand why the
> > > sessionlistener is designed this way...
> >
> > Well, the servlet spec does mandate calls in this order ...
> > which makes
> > much more logical sense than the alternative (session is
> > destroyed but it
> > still has things in it???).
> >
> > For your problem at hand, some appropriate database design
> > should do the
> > trick -- simply expose session_id as a column in the database tables
> > containing the transactional information. In your sessionDestroyed()
> > method, execute a SQL statement like
> >
> > delete from transaction_table where session_id = ?
> >
> > because you can still get the session id out of the session destroyed
> > event. You'll want to consider indexing on session_id to make this
> > operation run quickly enough.
> >
> > Craig McClanahan
> >
> >
> > > (Explanation please ?)
> > > A workaround I thought, was to use the attributelistener instead.
> > > When one attribute I choose is removed, I understand the
> > next step is the
> > > session to be removed.
> > > So, I use this attribute value for my work.
> > > Offcourse, it's not perfect and it might be pronable to
> > mistakes, but this
> > > is the fastest way for me to solve the problem.
> > > Regards,
> > > Tamir
> > >
> > >
> > > -----Original Message-----
> > > From: Software AG [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, June 24, 2002 1:25 PM
> > > To: Tomcat Users List
> > > Subject: SessionListener does not get enough information
> > >
> > >
> > > Hi there.
> > >
> > > I have a web application that stores some information into
> > a database.
> > > Now if the "transaction" is not complete (which means the
> > user did not go
> > > through a page asking "do you want to save [y/n]?") all
> > stored data shall be
> > > dropped again. I detect this "dropped transaction" with a
> > SessionListener,
> > > since after some time all inactive sessions are discarded.
> > >
> > > The problem is now that when the
> > SessionListener.sessionDestroyed method is
> > > called, all attributed have already been removed from the
> > session, so I do
> > > not really know what data needs to be deleted.
> > >
> > > In my eyes the real solution is to change the code in
> > > StandardSession.expire() to first fire the event and then clear the
> > > attributes. But I do not want to rely on anyone installing that web
> > > application to have a modified version of Tomcat.
> > >
> > > Does anyone know about an elegant workaround for this problem?
> > >
> > > Hiran
> > >
> > > --
> > > 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]>
>
>
> --
> 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]>
