Configuration de la persistance de session de Liberty
Lorsque les données de session doivent être maintenues suite à un redémarrage du serveur ou à une panne inattendue du serveur, vous pouvez configurer Liberty pour conserver les données de session dans une base de données. Cette configuration permet à plusieurs serveurs de partager les mêmes données de session et de récupérer les données de session dans le cas d'une reprise en ligne.
Pourquoi et quand exécuter cette tâche
Pour configurer un ou plusieurs serveurs dans Liberty pour conserver les données de session dans une base de données, suivez les instructions décrites ci-dessous.
Procédure
- Définissez une configuration de gestion de session partagée que vous pouvez réutiliser sur tous vos serveurs.
Vous devez au moins suivre les étapes suivantes :
- Activez la fonction sessionDatabase-1.0.
- Définissez une source de données :
<dataSource id="SessionDS" ... />
- Faites référence à la source de données dans la configuration de la base de données de session.
<httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS" ... />
- Faites référence à l'emplacement de stockage permanent dans la configuration de la gestion de session.
<httpSession storageRef="SessionDB" ... />
Remarque : L'attribut storageRef de l'élément httpSession et l'attribut id de l'élément httpSessionDatabase ne sont pas obligatoires. Si la fonction sessionDatabase-1.0 est activée et l'élément httpSessionDatabase fait référence à une source de données valide, la persistance de session est activée même si l'attribut storageRef n'est pas défini.Voir Database Session Persistence pour obtenir des détails sur les éléments httpSession et httpSessionDatabase.
Par exemple, vous pouvez créer un fichier nommé ${shared.config.dir}/httpSessionPersistence.xml comme suit :<server description="Demonstrates HTTP Session Persistence Configuration"> <featureManager> <feature>sessionDatabase-1.0</feature> <feature>servlet-3.0</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="${httpPort}"> <tcpOptions soReuseAddr="true"/> </httpEndpoint> <fileset id="DerbyFiles" includes="*.jar" dir="${shared.resource.dir}/derby/client"/> <library id="DerbyLib" filesetRef="DerbyFiles"/> <jdbcDriver id="DerbyDriver" libraryRef="DerbyLib"/> <dataSource id="SessionDS" jdbcDriverRef="DerbyDriver"> <properties.derby.client user="user1" password="password1" databaseName="${shared.resource.dir}/databases/SessionDB" createDatabase="create"/> </dataSource> <httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS"/> <httpSession storageRef="SessionDB" cloneId="${cloneId}"/> <application id="test" name="test" type="ear" location="${shared.app.dir}/test.ear"/> </server>
Remarque : Lorsque plusieurs serveurs sont configurés pour conserver les données de session dans une même base de données, ils doivent nécessairement partager la même configuration de gestion des sessions. Aucune autre configuration n'est admise. Par exemple, un serveur ne peut pas utiliser un schéma multiligne si un autre serveur utilise un schéma monoligne.Le plug-in de serveur HTTP utilise l'ID clone inséré dans l'en-tête de réponse/demande pour maintenir l'affinité de session entre les demandes. Si, en règle générale, l'ID clone reste inchangé, dans Liberty il est généré lorsque vous démarrez un serveur pour la première fois et est régénéré si vous démarrez le serveur avec l'option --clean. Pour un usage en production, l'affectation manuelle d'un ID clone garantie que cet ID est stable et que l'affinité des demandes est bien conservée. L'ID clone doit être unique pour chaque serveur et peut comporter entre 8 et 9 caractères alphanumériques ; il est spécifié à l'étape 3.
- Incluez la
configuration de gestion de sessions partagée dans la configuration de chacun de vos serveurs. Par exemple,
créez deux fichiers server.xml pour les instances
de serveur s1 et s2, comme ceci :
- ${wlp.user.dir}/servers/s1/server.xml
- ${wlp.user.dir}/servers/s2/server.xml
<server description="Example Server"> <include location="${shared.config.dir}/httpSessionPersistence.xml"/> </server>
Voir Utilisation d'éléments include dans les fichiers de configuration.
- Spécifiez des variables uniques dans le fichier bootstrap.properties de chaque serveur.
- ${wlp.user.dir}/servers/s1/bootstrap.properties
httpPort=9081 cloneId=s1
- ${wlp.user.dir}/servers/s2/bootstrap.properties
httpPort=9082 cloneId=s2
- ${wlp.user.dir}/servers/s1/bootstrap.properties
- Créez une table
de base de données pour la persistance des sessions avant de démarrer les serveurs.
- Si vous voulez changer la taille de ligne par défaut, le nom de la table ou le nom de l'espace table, consultez la rubrique Database Session Persistence pour des détails sur l'élément httpSessionDatabase.
Aucune action supplémentaire n'est nécessaire si votre serveur est installé sur l'un des systèmes d'exploitation répartis. Le serveur crée automatiquement la table.
- Si votre serveur utilise DB2 pour la persistance des sessions, vous pouvez augmenter la taille de page afin d'optimiser les performances lors de l'écriture d'un nombre élevé de données dans la base de données.
- Synchronisez les horloges système de toutes les machines hébergeant des serveurs Liberty. Si les horloges système ne sont pas synchronisées, l'invalidation de session peut survenir prématurément.
- Facultatif : Si nécessaire, intégrez la sécurité et des sessions HTTP dans Liberty. Par défaut, lorsqu'une session est créée et utilisée pour accéder à une ressource protégée avec la sécurité activée, seul le propriétaire d'origine de la session peut ensuite accéder à cette session. La sécurité de session (intégration de la sécurité) est activée par défaut.
- Facultatif : Si nécessaire, Installez et configurez le plug-in du serveur Web afin d'acheminer les demandes à chaque serveur que vous avez configuré. L'affinité de session n'est préservée que si votre configuration de plug-in spécifie les ID de clone correspondant aux ID de clone définis dans la configuration du serveur.

Nom du fichier : twlp_admin_session_persistence.html