The solution that worked for me on a web page like the one that you mention, rather to mess up with the server, I included a 'keepalive' javascript call to the server during the web session.
Every 100 seconds for instance, your web page should connect to the URL to get a 1x1 pixel size image but changing the URL with the timestamp to avoid the browser to grab it from the cache:
http://yourwebsite.com/imageonepixel.jpg?20120412103507
Look into this example for more details:
http://www.intelliproject.net/articles/showArticle/index/js_session_expired
Another example using Ajax:
http://blog.dayspring-tech.com/blog/2007/01/16/keep-session-alive-js-code/
jmerinoh
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Hockchai Lim
Sent: Thursday, April 12, 2012 6:41 AM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Http Session timeout clock
I was just exaggerating the processing time in the example. We have a web page that allows user to select multiple items for editing. Each items selected will then be displayed on the next screen for user to make change to. If there are too many items, the page will sometime expired on them by the time they edited all the items and clicks submit. Frustrating to the user, of course. So, Operation has posted a question to IT as when the time-out clock start. I researched on ibm site and all it says is that the timer starts when the session become passivated. I can't find anything about when/how a session becomes passivated. Thank you for your help on that question. Now, we are researching solution to reset the clock if user is typing or doing something on the screen.
"Maurice O'Prey" wrote in message
news:mailman.9188.1334179416.14575.web400@xxxxxxxxxxxx...
It will start somewhere in between the time the request was received and the response sent back, if you have a 12 minute server side processing time you have a serious problem!.
Are we trying to measure straws?
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Hockchai Lim
Sent: 11 April 2012 20:10
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Http Session timeout clock
Let see if example below can clarify my question a bit:
Let's assume that a http request is sent (post/get) to the server at 2:00PM.
After receiving the request, the server took 12 mins to process it and sent back the new page to the requester at 2:12PM. So, he requester is now sitting on this new page. For this new page, will the session time-out clock start at 2:00PM or 2:12PM or somewhere in between?
"Maurice O'Prey" wrote in message
news:mailman.9121.1334169973.14575.web400@xxxxxxxxxxxx...
You might like to clarify your question a bit and explain further the environment you are using and the types of problem you are encountering?
The session can expire from the first request (Post or Get) known as absolute expiration e.g. 10 minutes after FIRST request, OR sliding expiration e.g. 10 minutes since the LAST (Post or Get) request.
The method of the request Get/Post is irrelevant. If you do not know the difference between Post and Get then there are lots of good books out there...
Today's Topics:
1. Http Session timeout clock (Hockchai Lim)
----------------------------------------------------------------------
message: 1
date: Wed, 11 Apr 2012 08:40:25 -0500
from: "Hockchai Lim" <lim.hock-chai@xxxxxxxxxxxxxxx>
subject: [WEB400] Http Session timeout clock
Hello all,
Need some helps on a couple of questions regarding http session
timeout clock, thanks in advance
1) Am I correct to say that the time-out clock of a http session
starts when the Http Session becomes inactive (passivated)?
2) I'm assuming that a session timeout clock is cleared when requester
submits a http post to the server. Does the timeout clock starts
again as soon as the server received the post or does it starts right
after it returns the respond back to the requester?
Thanks
------------------------------
--
This is the Web Enabling the AS400 / iSeries (WEB400) digest list To
post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
End of WEB400 Digest, Vol 10, Issue 57
**************************************
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
midrange.com
