Just to give more details...

The session timeout setting is stored in our application's database.
Admins can change the session timeout from the UI we provide. We did
this to make it easy for our customers to set the desired timeout
rather than telling them going into web.xml and updating the timeout.

After a successful login we create the session, and set the timeout on
each session that is created using a HTTPSessionListener that is
attached to the context.

As far as I know, the session's lastAccessTime gets updated on each
request from the client (by the container), and there is no public API
to update the last access time. Perhaps can be done if we find the
Tomcat's internal session object, but prefer not to do it. Am I
correct or am I missing something?

Sai Pullabhotla



On Fri, Jul 8, 2011 at 9:31 AM, André Warnier <a...@ice-sa.com> wrote:
> Sai Pullabhotla wrote:
>>
>> We have an application that uploads files using a Servlet deployed in
>> Tomcat 6. While this works most of the times, occasionally we run into
>> issues uploading large files. If the upload takes longer then the
>> session timeout, the session gets invalidated right after the upload.
>> Tis means no further requests are accepted unless the user logs back
>> in. Is this the expected behavior? Is there any way to work around
>> this and keep the session active? I guess one way to fix this is to
>> have a large session timeout like an hour or two, but we prefer not to
>> do that for obvious reasons.
>>
> Responding in the absolute,
> if there is a session timeout functionality, then it must be based on
> a) a timeout value (a number of seconds e.g.)
> b) somewhere, an indicator of when the session was "last active", which gets
> updated at some point
>
> So the problem would boil down to knowing where this "last active" time is
> stored, and update it regularly during the file upload.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to