Sessions
Web requests are stateless, that is each request from a client (web browser) to a server is separate from any previous requests and no information about previous requests is available to the current request. You should think of each page as a separate Xbasic script - once one is finished, the next knows nothing about the previous. This can make the building of web applications quite difficult as the developer needs to track this state information within each web page returned by the server.
The Web Application Server uses sessions and Session Variables (as explained below) to overcome this limitation of web servers. as long as the server is licensed for a sufficient number of sessions, a request from a client will cause a new session to be created. The server will then associate future requests from that client with the same session until the session expires. A session expires when a request has not been received from the associated client within the time period set by Session Lifetime.
Sessions are normally tracked with cookies. However, clients are not required to accept cookies. Furthermore, you can turn off the use of cookies for session tracking altogether in the Web Application Server Control Panel. However when cookies are turned off or cookies are not enabled on a specific client computer, the server must work harder to track the session state, which has a performance impact. The recommendation is to leave cookies on and let the server automatically fall back to the cookieless operation only when required by a specific client connection.
When a session is created by the server, some information is automatically stored in it - the session ID and a timestamp. as an application developer, you can also store other information in the session in order to make it available to subsequent requests without explicitly passing it to that request.
To create a "session" level variable, simply name it session.varname. It will then be persistent across all page views and can be later referenced as session.varname in subsequent pages.
To illustrate this limitation of web programming and the session solution, look at the following example.
|
![]() | |
|
![]() |
In the example above, the second page has no access to the variables created in the first, so an error is generated when the second page tries to use the undefined variable greeting. But if the variable is instead created as session.greeting it will be available to all pages using the same session as can be seen below.
|
![]() | |
|
![]() |
The values automatically stored in each session by the server are:
session.SessionID session.Timestamp session.session_folder session.session_url |
session.SessionID is the unique identifier for the current session and is assigned by the server. session.Timestamp is a date variable and is automatically updated upon each client request within that session. session.session_folder is the full path to the temporary session folder - all files in this directory are removed when the session expires. session.session_url is the URL prefix to be used by a client browser to get to a temporary file that has been created.
Note: Session variables are local to the page (script) and must be passed to any functions defined on the page.
Note: When you are building an expression, you are not inside a running web session so there are no session variables available to the builder. You have to manually type in the names of the variables.
Note: If you create a session variable on one of your pages (e.g. session.myname = "George"), the variable will not exist until the page is submitted at least one time to the server.
Note: All variables created as part of a URL are of type character.
A Session ID is a unique ID that the Web Application Server assigns to each client. It uses the session ID to keep session information associated with the appropriate client. When the client sends a request to the Web Application Server, it needs to include this session ID so that the server knows which client is making the request.
The Web Application Server will use a cookie to track the user's session ID. If the user has disabled cookies, then the session ID will be appended onto the end of each URL.
Note: Even if a session times out, when it is re-established it will have the same session id as before. This is because the session id is really a unique browser id.
a5_default_path is a global variable available on all A5W pages. It contains the directory from which the page is being run.
End a session with SESSION.RESET(). There is no way to end a session when the browser is closed, since the browser does not send any notification to the server. In addition, unless you clear cookies, the next visit by that browser will use the same session id.
Server variables are similar to session variables, but persist over multiple sessions.
You can create, set, and read server variables in the same manner as with session variables. For example, you could create a server variable with:
dim server.announcement as c |
This variable is then available to all sessions and can be read or changed by any of them. For example, your A5W page could contain the following Xbasic code:
if (server.announcement <> "") then |
Server variables stay in memory until either the server is stopped, you call SERVER.RESET() to delete all server variables, or you remove an individual server variable with a delete statement.
You can view and modify existing (but not create) server variables from the Web Application Server Control Panel.
The Web Application Server creates a sub-folder under <webroot>\session_folders for each active session. To get a count of active sessions, use FILEFIND.GET() and count all the "D" types except "." and "..".
See Also
Request Variable, Status Codes, Configuring Internet Explorer, Protected Variables
Supported By
Alpha Five Version 6 and Above
Limitations
Web publishing applications only.