Configuration de la persistance de session pour le profil Liberty

Si les données de session doivent être conservées après le redémarrage du serveur ou un échec de serveur inattendu, vous pouvez configurer le profil Liberty pour qu'il conserve les données de session dans une base de données. Ce type de configuration permet à plusieurs serveurs de partager les mêmes données de session, qui peuvent par ailleurs être récupérées en cas de défaillance de l'un des serveurs.

Pourquoi et quand exécuter cette tâche

Pour configurer un ou plusieurs serveurs dans le profil Liberty de sorte qu'ils conservent les données de session dans une base de données, effectuez les opérations ci-dessous.

Procédure

  1. Définissez une configuration de gestion de sessions partagée qui puisse être réutilisée par tous vos serveurs. Vous devez effectuer les opérations suivantes au moins :
    1. Activer la fonction sessionDatabase-1.0.
    2. Définir une source de données :
      <dataSource id="SessionDS" ... />
    3. Référencer la source de données depuis la configuration de la base de données de session.
      <httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS" ... />
    4. Référencer l'emplacement de stockage persistant depuis la configuration de gestion des sessions.
      <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 que l'élément httpSessionDatabase 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 Eléments de configuration dans le fichier server.xml pour plus de détails sur les éléments httpSession et httpSessionDatabase.

    Par exemple, vous pouvez créer un fichier nommé ${shared.config.dir}/httpSessionPersistence.xml et ayant le contenu suivant :
    <server description="Démonstration d'une configuration de persistance des sessions HTTP">
    
        <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" jndiName="jdbc/sessions">
            <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.
    Méthode recommandée : Si l'affinité de session est importante pour votre application, définissez explicitement un ID de clone unique pour chaque serveur. Ainsi, vous ne dépendez pas de l'ID de clone par défaut généré par le serveur et vous êtes certain que l'ID choisi pour chaque serveur ne changera jamais.
  2. 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="Serveur exemple">
        <include location="${shared.config.dir}/httpSessionPersistence.xml"/>
    </server>

    Voir Utilisation d'éléments include dans les fichiers de configuration.

  3. 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
  4. 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 Eléments de configuration dans le fichier server.xml pour des détails sur l'élément httpSessionDatabase.
    • Pour plateformes répartiesAucune 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.
  5. 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.
  6. Facultatif : Si nécessaire, intégrez des sessions HTTP et la sécurité au profil 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.
  7. 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.

Icône indiquant le type de rubrique Rubrique Tâche

Dispositions pour les centres de documentation | Commentaires


Icône d'horodatage Dernière mise à jour: Wednesday, 2 September 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=twlp_admin_session_persistence
Nom du fichier : twlp_admin_session_persistence.html