tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Software AG <...@stark-verlag.de>
Subject AW: SessionListener does not get enough information
Date Tue, 25 Jun 2002 08:47:14 GMT
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.

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...?

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.

Hiran


> -----Urspr√ľngliche Nachricht-----
> Von: Craig R. McClanahan [mailto:craigmcc@apache.org]
> 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 <tamir@movious.com>
> > Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > To: 'Tomcat Users List' <tomcat-user@jakarta.apache.org>
> > 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:sag@stark-verlag.de]
> > 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: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>
>
>


--
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