Thanks for all the responses here are my thoughts:

the "-1" idea causes a problem because a user could just close the browser and we 
would not know when to invalidate the session (memory leak)

the html page sends a pseudo request is a good one, but we really only wanted to have 
the keep alive when the remote app was open and the html does not know that.

We may change our paradigm that the keep alive is from the html page, and might 
simplify this.

Thanks again,

Jay

-----Original Message-----
From: Dale, Matt [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 10:43 AM
To: Tomcat Users List
Subject: RE: Can you ever update a sessions access time?



One method i've used to maintain a session is a meta refresh on the html pages, this 
may or may not be appropriate to your app though.

-----Original Message-----
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: 11 May 2004 15:36
To: Tomcat Users List
Subject: RE: Can you ever update a sessions access time?



Hi,

>       Our need for this is that we have a java application that is
launched
>remotely by a control web-page.  As long as the remove application is
>active we do not want to the session that launched it to die.
>Unfortunately these were the requirements given to me, I just need to
see
>if it is possible.

You should probably scream a bit at the person who gave you the
requirements ;)

What about setting session-timeout to -1 in your web.xml?  That means
sessions won't timeout due to inactivity, and will become invalid only
if you explicitly invalidate them.  Then you don't have to worry about a
kludge keep-alive solution.

Yoav



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to