Pre-launched sessions

ONLINE HELP
WINDEV, WEBDEV AND WINDEV MOBILE

Version:

Home | Sign in | English

Help

Editors

Window editor and page editor

Pre-launched sessions

Overview

Importance of pre-launched sessions

Implementation

See also

InPrelaunchedSessionMode (Function)

Pre-launched sessions

Overview

A pre-launched session is a session of a Web site (or webservice) automatically started on the Web server from the WEBDEV Application Server.

Pre-launched sessions are used to speed up the display of pages by performing long processes in advance: connecting to databases, loading page configurations, etc.

Pre-launched sessions can be used with WEBDEV sites in Session and AWP modes and with SOAP and REST webservices. This operating mode is identical in any case.

Remark: Pre-launched sessions are allowed on the unlimited server or on the 10-connection server. They are not enabled on the development computer.

Importance of pre-launched sessions

Principle of a request for displaying an Active WEBDEV Page

To understand the importance of pre-launched sessions (especially for Active WEBDEV Pages), let's take a look at the principle of Active WEBDEV Pages.

When a Web user performs a request from an AWP page, the following operations are performed:

The request is transmitted from the browser to the Web server.
The Web server studies the request.
The Web server transmits the request to the WEBDEV application server.
The WEBDEV Application Server:
- loads the project corresponding to the page.
- runs the project initialization code, then the page code.
- returns the response to the Web server.
The Web server returns the response to the browser.

Benefit of pre-launched sessions

When displaying an Active WEBDEV Page, each call to the WEBDEV Application Server is entirely independent.

Consequence: For each request (and therefore for each change of page, for each Ajax call), the WEBDEV Application Server re-loads the project and re-runs the initialization code. The project initialization code often runs "long" operations:

connecting to the database,
loading configuration files,
...

The pre-launched sessions ask the WEBDEV Application Server to perform these operations in advance.

Therefore, when the request of the Web user reaches the WEBDEV Application Server, the application server only has to run the request and to return the result.

Pre-launched sessions therefore have a benefit in terms of response time since part of the code is executed in advance. However, pre-launched sessions do not reduce the load on the server (the code is still executed) and do not replace the optimization of initialization codes.

Implementation

Steps to follow

To implement pre-launched sessions in a WEBDEV project:

Enable the detection of errors specific to pre-launched sessions.
Correct the errors by using the "Initializing the project after connection to the site" event.
Enable pre-launched sessions on the WEBDEV Application Server.

Enabling the detection of errors specific to pre-launched sessions

If your project uses pre-launched sessions, some functions can no longer be used when initializing the project.

To know potential problems that may occur when using pre-launched sessions, simply enable the mode for detecting the errors specific to pre-launched sessions:

Display the "Compilation errors" pane if necessary: on the "Home" tab, in the "Environment" group, expand "Panes", select "Panes", and then select "Compilation errors".
In the pane of compilation errors, click .
The list of errors is displayed.

Remark: The detection of errors can also be enabled from the description window of the current configuration:

On the "Project" tab, in the "Project configuration" group, click "Current configuration".
In the "Compatibility" tab, check "Display compilation errors specific to pre-launched sessions".
Validate.
The list of errors is displayed in the error pane.

Correcting errors specific to pre-launched sessions

The errors of pre-launched sessions indicate which WLanguage functions are not allowed in the "Initializing" project event.

These functions are:


ASPDisplay	Calls an external ASP script and returns the result page in the current browser window.
BrowserIPAddress	Returns the IP address of the client computer connected to the WEBDEV site.
BrowserName	Returns the name of the browser of the Web user ("user agent").
BrowserPlatform	Returns the user's browser platform.
BrowserType	Returns the type of browser used by the Web user.
BrowserVersion	Returns the version of the browser used by the Web user.
CancelAWPContext	Deletes from the AWP context a variable that was added by DeclareAWPContext.
CancelWebserviceContext	Deletes from the webservice context a variable added by DeclareWebserviceContext.
CertificateClientInfo	Returns information about the certificate used by the client computer.
ConfigureAWPContext	Configures the operating mode of the AWP context.
Confirm	Displays a message in a standard dialog box that proposes "Yes", "No", "Cancel" and returns the user's choice.
ContextClose	Closes a page context.
ContextOpen	Opens a new page context without returning the information to the browser.
CookieRead	Retrieves the value of a cookie saved on the computer of Web user.
DeclareAWPContext	Used to declare a list of variables whose value will be persistent between the successive displays of Active WEBDEV Pages.
DeclareWebserviceContext	Used to declare a list of variables whose value will be persistent between the successive calls to a Webservice.
ExecuteDelayedProcedure	Runs a delayed procedure (in the WEBDEV application server).
FileDisplay	Displays a file in the browser of Web user.
FramesetDisplay	Displays a WEBDEV frameset in the user's browser.
FramesetRefresh	Refreshes a frameset displayed in the user's browser from the context on the server.
FramesetUse	Displays a WEBDEV frameset in the user's browser and closes all the current page and frameset contexts.
FreeAWPContext	Frees the AWP context in advance (on disk) to allow the other call on the same AWP context to be processed in parallel.
GglConnect	Manages authentication on a Google server (via the "OAuth 2.0" authentication mode).
gpwOpen	Opens the User Groupware login window or page.
IdentifierAWPContext	Returns the identifier of AWP context.
ImageArea	Returns the number of the image area clicked by the Web user.
ImageXPos	Returns the horizontal position (X) of the mouse cursor in relation to the specified Image control.
ImageYPos	Returns the vertical position (Y) of the mouse cursor in relation to the specified Clickable Image control.
OKCancel	Displays a message in a standard dialog box that proposes "OK" and "Cancel" and returns the user's choice.
PageCloseDialog	Closes the current page. This page was opened by PageDisplayDialog. A return value can be returned to the calling page.
PageDisplay	Displays a web page in the user's browser.
PageDisplayDialog	Displays a page in modal mode. This function is used to establish a dialog with the user. The page is displayed in the foreground while the opening page is displayed in the background, grayed by the DDW mechanism.
PageParameter	Returns the value of a parameter passed to the current page.
PageRefresh	Refreshes a page displayed in the user's browser from the context on the server.
PageUse	Displays a WEBDEV page in the user's browser and closes all page contexts currently open on the server.
PHPDisplay	Calls an external PHP script and returns the result page in the current browser window.
rssDisplay	Builds a RSS stream and returns the content of the RSS stream to the client.
ScriptDisplay	Calls an external script or page (.php, .asp, .mhtml or.mht) and returns the result page in the current browser window.
StringDisplay	Returns a specific string (or a buffer) to the client browser in response to a request.
UploadCopyFile	Saves on the server a file "uploaded" by the Web user. This upload may have been performed: via an "Upload" edit control. via a single-file or multi-file Upload control.
UploadFileName	Returns the name of a file "uploaded" by the Web user. This upload may have been performed: via an "Upload" edit control. via a single-file or multi-file Upload control.
WebserviceClientIPAddress	Returns the IP address of the computer using and calling the Webservice.
YesNo	Displays a message in a standard dialog box that proposes "Yes" and "No" and returns the user's choice.

To manage pre-launched sessions, two events are associated with the project:

"Initializing", a project event run before the request reaches the WEBDEV Application Server. This code is run when starting the pre-launched session.
"Initializing the project after connection to the site", run when the WEBDEV Application Server processes the request.

To correct the errors specific to the pre-launched sessions, simply move the corresponding code into the "Initializing the project after connection to the site" event.

When the site is compatible with the mechanism of pre-launched sessions, you can deploy it and enable the pre-launched sessions on the WEBDEV Application Server.

Enabling pre-launched sessions on the server

To enable pre-launched sessions for a site:

Start the WEBDEV administrator.
Display the "Configuration" tab.
Check "Allow pre-launched sessions.". By default, all the sites and webservices have 0 pre-launched sessions.
Select the site or the webservice to configure ("Sites" tab ot "Webservice" tab).
In the site parameters ("Sites" tab, "Parameters") or Webservice ("Webservices" tab, "Parameters"), specify the number of pre-launched sessions to use.
Validate.

Remarks:

Pre-launched sessions are counted in the total number of connections to the site (or to the Webservice). This information must be taken into account when configuring the WEBDEV Application Server.
The number of pre-launched sessions to be defined depends on the server usage and the number of requests.
- When a user connects (in the case of a site in session mode) or displays an Page (in the case of an AWP site), the WEBDEV application server uses a pre-launched session of this application if one exists, otherwise the WEBDEV application server launches a normal session (as if the site had no pre-launched sessions).
- The number of available pre-launched sessions is checked (per site) every second. So the number of pre-launched sessions depends on the number of connections (in the case of a site in Session mode) or displays of Page (in the case of a site AWP) per second.
- Attention, it is necessary to take into account the launching time of the pre-launched sessions: if a session takes more than one second to (pre)start, the number of pre-launched sessions actually available decreases.