Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 34348 invoked from network); 25 Jun 2002 16:34:59 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 25 Jun 2002 16:34:59 -0000 Received: (qmail 12483 invoked by uid 97); 25 Jun 2002 16:34:20 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 12422 invoked by uid 97); 25 Jun 2002 16:34:19 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 12373 invoked by uid 98); 25 Jun 2002 16:34:19 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Date: Tue, 25 Jun 2002 09:34:05 -0700 (PDT) From: "Craig R. McClanahan" To: Tomcat Users List Subject: Re: AW: SessionListener does not get enough information In-Reply-To: <51A779854605D41192C000508B8BC11C148EA0@hbmpdc.stark-verlag.de> Message-ID: <20020625091940.Y1747-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 25 Jun 2002, Software AG wrote: > Date: Tue, 25 Jun 2002 10:47:14 +0200 > From: Software AG > Reply-To: Tomcat Users List > To: 'Tomcat Users List' > 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 architect= ure > 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 poin= t > 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 s= o > much good for application programming..... And if not, it might be nice t= o > 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=FCngliche 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 > > > 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 =3D ? > > > > 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: > > > > > > For additional commands, e-mail: > > > > > > > > > -- > > > 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: > > -- To unsubscribe, e-mail: For additional commands, e-mail: