Support de gestion des sessions
Des fonctionnalités regroupées sous l'en-tête Gestion de session sont fournies par WebSphere Application Server. Elles prennent en charge l'interface javax.servlet.http.HttpSession décrite dans la spécification de l'API Java Servlet.
Conformément à la spécification de l'API Servlet 2.3, l'utilitaire de gestion de session prend en charge la sectorisation des sessions par modules Web. Seuls les servlets d'un même module Web peuvent accéder aux données associées à une session particulière. Plusieurs requêtes provenant d'un même navigateur, chacune spécifiant une application Web différente, génèrent plusieurs sessions avec un ID de session partagé. Il est possible d'annuler l'une de ces sessions sans affecter les autres.
Vous pouvez configurer un délai d'expiration de session pour chaque application Web. Une valeur égale à 0 (la valeur par défaut) signifie que la valeur du délai avant invalidation de l'utilitaire de gestion de session est utilisée.
Lorsqu'un client HTTP interagit avec un servlet, les informations d'état associées à une série de requêtes de ce client sont représentées sous forme de session HTTP et identifiées par un ID de session. L'utilitaire de gestion de session est chargé de gérer les sessions HTTP, d'assurer le stockage de leurs données, de leur allouer des ID et de tracer l'ID de session associé à chaque requête client, cette dernière tâche étant accomplie au moyen de cookies ou de techniques de réécriture des URL. Il peut stocker les informations relatives aux session de plusieurs manières :
- Dans la mémoire du serveur d'applications (procédé par défaut). Dans ce cas, les informations ne peuvent pas être partagées avec d'autres serveurs d'applications.
- Dans une base de données. Cette option de stockage est désignée par sessions persistantes de base de données.
Dans une autre instance WebSphere Application Server. Cette option de stockage est désignée par sessions de mémoire à mémoire.
Les deux dernières options sont appelées sessions réparties. Les sessions réparties sont essentielles à l'utilisation de sessions HTTP avec une fonction de secours. Lorsqu'un serveur d'applications reçoit une requête associée à un ID de session qu'il ne possède pas en mémoire, il peut obtenir l'état de session requis en accédant au magasin externe (base de données ou de mémoire à mémoire). Si le support de sessions réparties n'est pas activé, un serveur d'applications ne peut pas accéder aux informations de session pour les requêtes HTTP qui sont envoyées à des serveurs autres que celui sur lequel la session a été initialement créée. L'utilitaire de gestion de session utilise des techniques de mise en cache optimisée pour limiter autant que possible les accès au magasin externe, en particulier lorsque des requêtes consécutives sont acheminées vers le même serveur d'applications.
Le stockage de l'état des sessions dans un magasin externe offre également un certain degré de tolérance des pannes. Si un serveur d'applications est mis hors ligne, l'état de ses sessions actives est toujours disponible dans le magasin externe. Cette disponibilité permet à d'autres serveurs d'applications de poursuivre le traitement des requêtes ultérieures associées à ces sessions.
Le stockage des états de sessions dans un emplacement externe ne garantit pas complètement qu'ils seront préservés en cas de défaillance d'un serveur. Par exemple, si un serveur échoue alors qu'il est en train de modifier l'état d'une session, certaines informations seront perdues et il est possible que cela affecte les autres traitements réalisés ensuite avec cette session. Cependant, ce risque de perte d'informations reste limité dans la mesure où il n'existe que pendant un très court instant.
L'inconvénient de la sauvegarde des états des sessions dans un magasin externe est que les accès à cet emplacement externe consomment de précieuses ressources système. L'utilitaire de gestion de session peut réduire le nombre de ces accès, et donc minimiser leur impact sur les performances du système, en mettant en cache les données d'état des sessions au niveau du serveur. Lorsque plusieurs requêtes consécutives sont dirigées vers le même serveur, les données d'état requises peuvent être trouvées en cache. Les accès à l'état réel des sessions dans le magasin externe sont alors moins nombreux et ont donc moins de conséquences sur les performances du système.
