25 septembre 2012
publié par 
WEBDEV permet de créer différents types de sites Web afin de répondre à tous les besoins. Ce billet détaille le principe de gestion des sessions, dans le cas des sites dynamiques. Ne sont donc pas concernés les sites statiques, ou fonctionnant en mode AWP, sans session.

 

Par définition, un site dynamique conserve sur le serveur une "session" active qui permet de stocker toutes les informations de contexte sur les pages ouvertes, les données lues, les variables affectées... A chaque connexion d'un Internaute, une nouvelle session est donc lancée sur le serveur. Il s'agit d'un processus exécutable visible :
  • dans l'administrateur de WEBDEV (WD170ADMIN.EXE) (WD180ADMIN.EXE ...) sur le serveur (volet "Connexions"), il y a une ligne pas connexion,
  • dans le gestionnaire de tâches de Windows (volet "Processus"), il y a un exécutable WDSESSION.EXE (WD170SESSION.EXE en version 17, WD180SESSION.EXE en version 18) par connexion.

 

Première information intéressante, le "PID" du processus WD170SESSION.EXE montré par le gestionnaire de tâches de Windows, correspond à la colonne "ID" montrée par l'administrateur de WEBDEV (WD170ADMIN.EXE). Ce même identifiant unique, est accessible par programmation dans le code serveur d'un site, grâce à la fonction ExeDonnePID. En phase de débogage, de test de montée en charge, cet identifiant peut permettre suivre précisément les effets d'une connexion donnée sur le serveur :
  • dans le site en test on peut afficher dans un champ le PID correspondant à la session sur le serveur,
  • sur le serveur on peut "surveiller" le WDSESSION.EXE (WD170SESSION.EXE en version 17, WD180SESSION.EXE en version 18) correspondant en fonction des actions faites dans le site, depuis le navigateur en test.
Typiquement cela permet de vérifier si un traitement de données est trop consommateur de mémoire, ou de temps, et doit par exemple être déporté du site vers une procédure stockée, un programme "back-office"...

 

Second point important, et objet principal de ce billet, la libération des sessions. En effet puisque chaque connexion nécessite le lancement d'un processus sur le serveur, chaque déconnexion d'un Internaute nécessite l'arrêt du processus correspondant. Idéalement, le site doit contenir un bouton de déconnexion, qui se chargera d'appeler la fonction FinProgramme. Son appel provoque ainsi en cascade toutes les actions nécessaires :
  • exécution du code de fermeture du projet,
  • arrêt du processus WD170SESSION.EXE qui avait été lancé lors de la connexion, et donc libération définitivement du contexte, et de toutes les ressources qui avaient été allouées.
Dans la pratique, c'est le plus souvent la croix de fermeture du navigateur qui est utilisée par l'Internaute, plutôt que l'option prévue dans le site. Dans ce cas, la fermeture du navigateur n'a plus aucune action sur le serveur, le contexte WD170SESSION.EXE correspondant est donc conservé en mémoire sur le serveur. La gestion de ces sessions devenues inactives est à la charge du serveur d'application de WEBDEV. En effet dans l'administrateur, globalement ou pour chaque site, un "timeout" peut être donné (volet "Sites") : "Déconnecter les utilisateurs inactifs depuis ...". Grâce à ce mécanisme, même si l'internaute quitte le site via la fermeture de son navigateur, ou du volet du navigateur qui contenait le site, au bout du timeout donné le serveur d'application de WEBDEV fera :
  • l'appel du code de fermeture du projet,
  • la suppression du processus WD170SESSION.EXE devenu inutile.
Attention pour ce cas de fermeture, il faut limiter le temps d'exécution du code de fermeture du projet, afin qu'il puisse être exécuté dans sa totalité avant la suppression définitive du processus. Il faut donc préférer une libération progressive au fur et à mesure dans les pages, plutôt que de tout regrouper en fin de projet. Cela permet également de limiter l'occupation mémoire de chaque session.

 

En fonction de chaque site, il est donc primordial de bien évaluer le détail de déconnexion des sessions inactives à configurer sur le serveur. En effet, un timeout :
  • trop court risque de déconnecter l'Internaute de façon intempestive (retour ERR_DISCONNECTED_BY_ADMIN),
  • trop long va accumuler des sessions sur le serveur, et donc consommer inutilement des ressources.
Il n'y a donc pas de valeur "recommandée", le bon temps sera dépendant de la nature du site, de l'activité de l'internaute et de l'utilisation faite du site...

 

Dans le cas particulier d'un site dans lequel on ne veut pas que l'utilisateur puisse être déconnecté en cas d'inactivité, et pour lequel le serveur ne peut pas accepter des sessions inactives trop longues, il y a une astuce en utilisant la technologie Ajax :
  • dans l'administrateur de WEBDEV sur le serveur, réduire le délai de déconnexion des sessions inactives à un temps très court,
  • exécuter par timer (fréquence d'appel inférieure au timeout court donné sur le serveur) un traitement serveur (appel d'une procédure serveur avec AjaxExécuteAsynchrone) dans toutes les pages du site.

 

Par ce principe, le serveur voit ainsi une activité constante (appel de la procédure serveur), le délai d'inactivité n'est donc jamais atteint : aucune déconnexion intempestive n'est possible. Par contre, dès que le navigateur est fermé, il n'y a plus l'appel du serveur, grâce au timeout court la session correspondante est supprimée. Une illustration complète de ce principe avec un exemple est proposé si besoin l'exemple page 20 de la LST 69 : "Gestion des Sessions WEBDEV".


== Mise à jour 30/9/2021 ==
Sur ce thème à partir de la version 26 (nouveauté 926) il devient possible d'activer ou de désactiver le "heartbeat" de la session courante avec la nouvelle fonction SessionHeartBeatActive.
Le but du "heartbeat" de session est de décharger le serveur en fermant plus tôt les sessions du serveur (par exemple en détectant les sessions pour lesquelles le client a navigué hors du site).

 

 

 

< Retour