RE: SessionListener does not get enough information

[tamir]

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:

For additional commands, e-mail:


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

Re: SessionListener does not get enough information

[Gabriel Gajdos]

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:   
For additional commands, e-mail: 

RE: SessionListener does not get enough information

[Craig R. McClanahan]

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

RE: SessionListener does not get enough information

[tamir]

Hi Hiran,
I also read very carefully the email conversation between you and Craig.
It was very interesting, and I must agree I liked your idea of an event of
pre-closing the session.
I wonder whether other serlvet containers implement it the same way. (bea ?)

Tnx,
Tamir

-Original Message-
From: Software AG [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 26, 2002 3:18 PM
To: 'Tomcat Users List'
Subject: AW: SessionListener does not get enough information


Hi, Tamir and Ralph.

Just wanted to let you know I meanwhile implemented my solution as you two
recommended - put all the functionality into a bean, have it listen to
SessionAttribute events and assume it is unbound on session timeout only.
However I think here is a pitfall in the spec and Tomcat implementation that
should be clarified.

Thanks for your help.

Hiran

> -Ursprüngliche Nachricht-
> Von: tamir [mailto:[EMAIL PROTECTED]]
> Gesendet: Montag, 24. Juni 2002 14:54
> An: 'Tomcat Users List'
> Betreff: 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]>


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