Reprise en ligne des sessions HTTP
Dans un environnement en cluster, toutes les requêtes pour une session particulière sont dirigées vers la même instance de serveur dans le cluster. Dans une session, une fois établie par un utilisateur (par exemple, en se connectant), l'utilisateur est servi par la même instance de serveur pendant la session. Afin de vérifier quel serveur gère les demandes utilisateur pour une session vous pouvez afficher le portlet des paramètres globaux. Ce portlet affiche le nom de noeud du serveur qui gère les demandes. Si l'un des serveurs du cluster échoue, la demande est redirigée vers un autre serveur du cluster. Si la prise en charge des sessions réparties est activée, le nouveau serveur peut accéder aux données de la session à partir de la base de données ou d'une autre instance de serveur.
- Windows™ et :UNIX™Linux™ Sessions réparties
- IBM® i: Prise en charge des sessions réparties
- Sessions réparties
La prise en charge par défaut de la reprise en ligne est disponible pour HCL ainsi que pour tous les portlets installés avec le produit. Pour bénéficier de la prise en charge de la fonction de reprise en ligne avec les portlets que vous avez développés, vous devez vous assurer que vos portlets sont correctement implémentés.
Reprise en ligne et données perdues
Données stockées dans la mémoire JVM. Cette opération n'est pas gérée par le serveur d'applications ou le serveur HCL, car la réplication pourrait être perdue en cas de reprise en ligne. Même avec la prise en charge de session répartie, les utilisateurs ne peuvent pas récupérer les informations validées non stockées dans des sessions ou dans d'autres zones de données répliquées. Dans ce cas, les utilisateurs peuvent relancer une transaction après une reprise en ligne. Par exemple, si vous travaillez avec un portlet et avez navigué entre plusieurs écrans lorsqu'une reprise en ligne est effectuée, vous revenez à l'écran initial. Si vous tentez de déployer un portlet lorsqu'une reprise en ligne se produit, il se peut que le déploiement échoue. Vous devez par conséquent redéployer le portlet. La validité des sessions de connexion utilisateur est maintenue malgré les échecs de noeuds lorsque la prise en charge des sessions réparties est activé.
Lorsqu'un portlet ne prend pas en charge une reprise en ligne, un message "Portlet unavailable" s'affiche pour le portlet lorsqu'elle se produit. Si un portlet prend en charge une reprise en ligne partielle ou incomplète, il se peut que certaines données affichées avant la reprise disparaissent une fois celle-ci effectuée. Il se peut que le portlet ne fonctionne pas comme attendu. Dans ces cas extrêmes, cet utilisateur doit se déconnecter puis se reconnecter afin de reprendre le fonctionnement normal.
Après une reprise en ligne, la demande est réacheminée vers un autre membre de cluster par le plug-in de serveur Web. La plupart des navigateurs génèrent une requête GET en réponse à une réacheminement après que vous avez soumis une requête POST. Cela garantit que le navigateur n'envoie pas les mêmes données plusieurs fois sans que l'utilisateur en soit informé. Toutefois, après la reprise en ligne, les utilisateurs doivent régénérer la page ou soumettre à nouveau le formulaire pour récupérer les données POST.
Reprise en ligne pour le portlet de création
Vous pouvez configurer la prise en charge des sessions réparties dans WebSphere® Application Server, que ce soit pour les sessions persistantes ou la réplication de session intermémoire. Configurez le paramètre Custom tuning parameters afin de déterminer les attributs de session à répliquer ainsi que la fréquence de réplication. Vous pouvez aussi sélectionner un niveau d'optimisation, de "Très élevé" pour maximiser les performances, à "Faible" pour optimiser la reprise en ligne. Pour que les informations de session soient conservées après la reprise en ligne, définissez le niveau d'optimisation personnalisée afin que tous les attributs de session soient optimisés.
Si la fréquence d'écriture est "basée sur l'heure" avec une fréquence de 10 secondes, les modifications effectuées dans les 10 secondes qui suivent la reprise en ligne sont perdues. Si la fréquence d'écriture est définie sur "Fin du service de servlet", la session du portlet Création reste intacte après la reprise en ligne.
Dans le cas d'une reprise en ligne ou d'un dépassement du délai d'attente de session, un utilisateur Web Content Manager peut revenir à l'écran initial du portlet Création. Les données non validées sont perdues, y compris les valeurs pour les nouveaux éléments de contenu ou les modifications apportées à un élément existant. Il n'y a cependant aucune interruption de service et l'utilisateur peut continuer à travailler.