tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: SessionListener does not get enough information
Date Mon, 24 Jun 2002 16:27:45 GMT

On Mon, 24 Jun 2002, tamir wrote:

> Date: Mon, 24 Jun 2002 14:54:00 +0200
> From: tamir <>
> Reply-To: Tomcat Users List <>
> To: 'Tomcat Users List' <>
> 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 []
> 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:
> <>
> For additional commands, e-mail:
> <>
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message