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. 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:[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]
Re: AW: SessionListener does not get enough information
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
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]
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... (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]
AW: SessionListener does not get enough information
Define a class (bean) that store the information that the user has to confirm. Let this classs implement the HttpSessionBindingListener and do the 'rollback' in the valueUnbound() method. -Ursprüngliche Nachricht- Von: Software AG [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 24. Juni 2002 13:25 An: Tomcat Users List Betreff: SessionListener does not get enough information 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. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SessionListener does not get enough information
Another idea (I do not like HttpSessionBindingListener): On sessionDestroyed you should be able to get Session ID information. So just write your method: MySessionDataDropper.drop(String sessionID) or (MyObject data) which will drop all data identified by sessionID. Imagine: You have one Hashtable (scope application) with objects for your session identified by key sessionID String. On sessionCreated you add some pointer to your temporary data On sessionDestroyed you just take the correct object and drop its data. Another way is to use finalizers (= I do not recommend). GG -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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]
