Caves Travel Diving Graphics Mizar Texts Cuisine Lemkov Contact Map RSS Polski
Trybiks' Dive Texts SessionTimeout in Intraweb YAC Software
  Back

List

Intraweb and MaxConnections

A Case for FreeAndNIL

Intraweb as an Apache DSO module

"Device not supported" in Intraweb

Automated GUI Testing

Fix for Highslide HTML Slides

Random()'s Determinism

Rounding and precision on the 8087 FPU

Clicking on links in JavaScript

PHP's mail()

File | Save Atavism

SessionTimeout in Intraweb

Using TChart with Intraweb

Unknown driver: MySQL

Automated GUI Testing in VMs

TIdMessage's CharSet

Product Peer Reviews - Introduction

Software Guarantees

Automated Testing of Window Forms

TChart - Missing Labels in Axes

Calculating Positions of HTML Elements

Memory Leaks and Connection Explosions in DBExpress

CSS for Scrollbars on Pages and in Frames

Controlling Conditional Defines and Compilation Switches

Turning Browser Caching off when Displaying Images Using PHP

Detecting Memory Leaks with DUnit

last_insert_id() and DBExpress

YAC Data Language

Registering Extensions

DBExpress and Thread Safety

Forms as Frames

Checking Dangling Pointers vs. the New Memory Manager

</form> ... <form>

Accessing Protected Members

SessionTimeout in Intraweb
TIWServerController's SessionTimeout property defines the time of inactivity, in minutes, after which a session is automatically destroyed.

There are at least two problems with this approach:
  1. When a user stops working with your application for a period longer than the timeout, and then returns to the application (for instance, after a lengthy phone call), the browser will happily display Intraweb's timeout screen. You can restart the application, but now all session specific, non-persisted data, is lost...
  2. So you set a longer timeout, let's say, an hour. This doesn't solve the problem above, really, it only makes it less probable. On the other hand, if the user closes the browser window without explicitly closing Intraweb's session (without logging out or performing a similar action), an "active" session is left hanging in Intraweb for the period specified in SessionTimeout. This takes up resources, obviously, but more importantly, may also delay saving user's data (until, for instance, the session is destroyed by Intraweb).
In applications where sessions take up a lot of memory, or use other resources, you can quickly run out of those resources if you have a lot of visitors whose session are left dangling...

Thus, the following solution (based on a comment here):
  1. Set the SessionTimeout to 1 minute.
  2. Add a TIWTimer component to your forms (I use a base form for that).
  3. Set the OnAsyncTimer event to an empty handler.
  4. Set the timer's interval to 20 seconds or so.
This solves problem #1 - the user, as long as he/she has a browser window open, will not get a timeout message.

This helps with problem #2 - the longest period that an active session will not be destroyed is... 1 minute.

The 20 second interval in the timer ensures that a timer will refresh the session 2 to 3 times per minute (modulo networking problems).

Note that each such call sends data to the server, about 2kB worth. So you may need to balance the timeout period with the timer's interval a bit, if that starts to be a problem. And in case of networking problems, you may leave the timer's interval, but raise the session timeout to several minutes.
  type
    TYIWForm = class(TIWAppForm)
      HeartbeatTimer: TIWTimer;
      procedure HeartbeatTimerAsyncTimer(ASender: TObject; AEventParams: TStringList);
    end;
  . . .
  procedure TYIWForm.HeartbeatTimerAsyncTimer(ASender: TObject; AEventParams: TStringList);
  begin
    // Don't do anything,
    // but don't let Delphi's IDE remove this method automatically.
  end;
It doesn't get any simpler than that... :-)

Top

Comments
Alas!
No comments yet...

Top

Add a comment (fields with an asterisk are required)
Name / nick *
Mail (will remain hidden) *
Your website
Comment (no tags) *
Enter the text displayed below *
 

Top