tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Uploading large files and session timeout
Date Fri, 08 Jul 2011 20:49:21 GMT
Caldarale, Charles R wrote:
>> From: Sai Pullabhotla [] 
>> Subject: Re: Uploading large files and session timeout
>> 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.
> Your servlet could call HttpSession.setMaxInactiveInterval() as needed to prevent a timeout.

The do this cleanly, the servlet would need to call HttpSession.getMaxInactiveInterval() 
at the beginning, to save the existing value, then call 
HttpSession.setMaxInactiveInterval() to set a new one for the duration of the transfer, 
then process the upload, then at the end call HttpSession.setMaxInactiveInterval() to 
reset the old value, right ?

But there is still something that to me seems illogical :

Since the "session expiration" is determined in function of the MaxInactiveInterval and 
the lastAccessTime, and since Tomcat has no way to know at the beginning of a request, how

long this request will take to process, I would think that the lastAccessTime would be 
updated *at the end* of a request, not at the beginning.

And if so, how can it happen that a session is expired after even a long file upload ?
In other words, are there circumstances which may cause the lastAccessTime /not/ to be 
updated ?  (such as, if the user interrupts the upload, or an error happens in the middle


If I go by the name, HttpSession.setMaxInactiveInterval() changes the timeout for this 
session.  Which means that after doing that, and finishing the file upload, then as long 
at this same session remains valid, further requests in this same session will be handled

with the new timeout.  And as long as that user keeps accessing the application, the 
timeout will remain at

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

View raw message