Since the dawn of Web, each request for a page required just one page visit. You set the address, hit the Go button, wait for the page markup to download, see the output. You're happy. You read the page, you click a button somewhere and you either revisit (re-download) the page with some updated contents or you move to another page. It's the same user's session, as long as not much time has elapsed between two successive visits.
By default, a user's session times out after something like twenty minutes of inactivity. More precisely, if the user doesn't post back to the server for more than the specified number of seconds, within a given session, the session is considered expired. Any successive call from the same client is refused with a session timeout error. This is the Web, and it's always been like this. Until AJAX came along.
With AJAX, each page visit—defined as the action of pointing the browser to a specified page—may originate multiple requests and, of course, all of them are from within the same user's session. The beauty of AJAX is that users can interact with the page functions without fully refreshing (i.e., revisiting) the page itself. However, the user can also operate within the page locally without the need of posting back for many minutes.
Honestly, with the old Web model, it's hard to imagine a user that sits still in front of her browser looking at the same page for more than just a few minutes. Session timeouts typically originate when the user leaves the workstation, gets engaged in a long phone call or a nice chat with a colleague, or really spends a lot of time editing some text in the page. In general, behaviors that may originate a session timeout are a kind of a special event in a classic Web applications—occasional but not rare. In AJAX applications, many more events, and frequent indeed, may originate a session timeout. In an AJAX application, the likelihood that a user is actively working with the page but doesn't post back is definitely higher than in a classic Web application.
In this context, a new problem arises—how can you keep the session alive when the user may not post back for a while? Actually, there are not many tricks you can play here; yours is a kind of set route. As a developer, you have to ensure that the session is maintained alive on the server if this is essential for the page's functionality. There's a simple way of doing this—set up a client timer and warn the user a few minutes before the session expires. In ASP.NET, a session expires after 20 minutes, even though this is a configurable parameter that a developer knows. In the end, if the user hangs on a page for about the time it takes to expire the session, you present a message and ask what to do. What's required to keep a session alive? A postback to the Web server is enough. Seems to be the perfect solution? Read Eric Pascarello's Session Warning to Developers for potential drawbacks with this trick.
